Why API as a Strategy

By Emile Kfouri September 07, 2008

First, let’s start with a little quiz. I promise it won’t be too hard.

Question: What is common between AutoCAD, Microsoft Office, eBay, Amazon, Google, Adobe Photoshop, Microsoft Visual Studio 2008, Microsoft Windows Vista, Autodesk 3ds Max, LEGO MINDSTORMS and the Apple iPhone?

Answer: Let’s see. At first glance - software and hardware, OS and Web 2.0, developer tools and productivity applications. But they are also all market leaders in their field and they all have APIs (Application Programming Interface) that are used by many companies to build businesses and products on top of them. The value to third-party developers is to avoid recreating the functionality in the base product and as a result, simply focus on creating value-added functionality. Third-party developers also have an automatic installed base of millions to which to sell.

What is an API?

API stands for Application Programming Interface. In short, it is the equivalent of a Graphical User Interface (GUI) for programmers. Users interact with a program using the GUI, programs “interact” with other programs using the API.

APIs can run the gamut from simple access to application data to the ability to do anything that can be done through the GUI and more. If you do not have an API, the question is, do you need an API? Well, in many ways it is the entry ticket to the big leagues where the market- leading products play.

Within weeks of the original Lego Mindstorm debut, Kekao Proudfoot reverse engineered the RCX brick (hardware) and posted his findings online. Other engineers then used his findings to create Mindstorm tools, including an operating system and a C-like programming language. Lego had the ability to stop them but instead decided to let this community flourish. 'We came to understand that this is a great way to make the product more exciting,' Lego’s Nipper said.
From Geeks in Toyland By Brendan I. Koerner - Wired Magazine February 2006.

In the case of the LEGO MINDSTORMS, it got an API completely by accident (someone hacked into the hardware). The result was a tremendous growth in that market because now their product was no longer just for kids. In fact, a large portion of the people who bought it were adults who wanted an easy way to play with robots. (And tell me, who among us did not have a childhood dream of creating their own do-good or evil robot?)

Why an API?

There are many advantages to having an API including:

  • Scaling Development

  • Converting Competitors Into Partners

  • Scaling Market Reach

  • Empowering Users

Scaling Development
The API provides a way to add and enhance a program without having to get into the guts of the program itself. An API allows groups of developers (internal, partners or contract developers) anywhere in the world to enhance the product with minimal coordination. The advantages go beyond better architecture of the program’s source code because API users are actually completely shielded from the program’s internal source code. This in turn provides the opportunity to add value to your product outside of your regular development cycle. Interestingly, users who develop or purchase products that work on the API-based application are more reluctant to try alternatives because of the investment users have made in the product.

Converting Competitors Into Partners
It is clear that partnerships can make companies stronger by developing synergies between products and cross-selling to each other’s existing clientele. The API can help turn your competitors into partners by allowing them to build solutions on top of your product’s functionality. This concept lets partners leverage the existing capabilities of your program and enhance it by using their expertise and know-how to create new and innovative solutions. This approach sure beats duplicating the functionality of your base product first. In return, they can get access to your user base or open up new markets for you with less investment in software development from either side.

A few years ago, the Autodesk Revit product design team was doing a workflow analysis to see where users were wasting the most amount of time. They noticed that printing large drawings was taking a lot of time and had many problems. When the team assessed the problem, they realized that even the simplest solution could not be completed in time for the current release and waiting for the subsequent release was unacceptable. They decided to expose a few new APIs related to printing and create an Add-in using the Revit API. It was made available in between the releases. The add-in quickly became one of the most popular add-in downloads for the product.

The API let the Revit team address a problem quickly and push value out to the users rather than making them wait for the next release. An interesting by-product of the new API was that three different companies used the same API to create their own products too, building more value on top of Revit.

Scaling Market Reach
As you have probably figured out, the API lets one build on top of a product and expands its capabilities. An API opens up the opportunity for ways to tap into markets and geographies you would not otherwise have the resources or expertise to get into. The ability to have your product “countrified” with not just translation but also with features and content relevant to that market can be a very compelling offering in a new market. An API offers the possibility of creating or modifying features to suit specific markets and it can also help automate the creation of content relevant to your market.

Empowering Users
Simply put, an API empowers end-users by making their product do things the original developers did not build into the product. It also lets users customize the product to better fit their needs and workflow. The real secret is to create features and APIs that are not dead ends, but rather extensible solutions used to solve more specific or specialized problems with just a little bit of effort (this is sometimes called the Final Mile problem).

Chicken or Egg
So, you may be wondering, “Are these companies market leaders because they have an API or did they become market leaders first and then build an API to protect and consolidate their leadership?” The answer is, it depends. Both strategies work and have been very successful. In my experience, starting with the consideration of API has always been a lot more economical in the long run, even if it means delaying your release. An API empowers users and partners to fill in product gaps and capture additional markets. The API provides more options and permits the scaling of a product from both a business and a technical point-of-view.

Build It and They Will Come
It is tempting to think that if you build it, they will come. Just creating an API is not enough. You need a complete strategy that includes great documentation, sample code, sufficient functionality, lighthouse partners, partner programs, developer support and co-marketing resources. The process takes time to take off but once it does, it is a gift that keeps on giving. However, in case you doubt the value of building a business around your API, take a look at what financial analysts said about Autodesk in 2006:

“…Autodesk has lots of competition. However, Autodesk continues to improve its product offerings, with both a strong engineering team and an army of over 2,500 third-party developers. The upshot is a powerful competitive advantage.”

Today there are over 3,100 companies comprising 13,000 Autodesk licenses. That is almost 2x the total number of employees at Autodesk. Those third-party developers are building solutions and businesses on top of Autodesk products and they have a tangible vested interest in Autodesk’s success. Building a business where other businesses want you to succeed is not a bad way to make a living, if you ask me.

AutoCAD (by Autodesk, Inc.) is the market leading Computer Aided Design (CAD) application in the world. It is used in architecture, engineering, manufacturing and entertainment. Nearly 30% of AutoCAD users have either developed or used custom applications that work on AutoCAD. Some are simple tools that automate repetitive or low skill tasks like printing many drawings. Some tools are complete applications built on top of AutoCAD such as COINS Framing - a residential home wood framing application. These applications, small and large, create very loyal AutoCAD users because the product is extremely flexible and the add-ins increase productivity.

Do I Need an API?

You still may be wondering if you really need an API and how to get started. The first question is quite simple to answer. If you answer YES to more than one of the following, then you need to seriously think about developing an API!

  • Will development ground to a halt if you double the number of developers on you product ?

  • Do you need to add features to your product without touching the internal source code?

  • Do you need partners to integrate with your product?

  • Do you need to add features for a geography or market that you do not have expertise in?

  • Are your users or partners asking to get access to your application’s data for downstream use?

  • Are your users or partners asking to programmatically populate data into your application?

  • Do you have aspirations for your product becoming a Platform and playing with the “Big Boys”?

The question of how to get started depends on your product. If you have an existing product, my recommendation is to start small and go after low-hanging fruit. Research the areas with the greatest opportunity and lowest technical barrier for entry. Find a user or partner in that space that just wants to access a small part of your application and build a simple API for that. Start slow and accept the fact you will make mistakes and learn from them. If you are starting a new product, start it from the ground up as an API-centric application. For both scenarios, be sure to build out the API to meet your long term strategic goals. In either case, you may need to make one or two key hires to fill in any gaps in your development or management groups to increase the possibility of success with the API.

The final recommendation that I always make is to utilize and continually test your own API. If it is not good enough for you to use, you cannot expect anyone else to use it either. This is often called the “eat your own dog food” principle. Personally, I try to avoid eating anyone’s dog food but I think it is meant metaphorically, which I suppose makes it easier to swallow.

Also, remember to be a great partner and to understand the co-dependency of the relationship. Partners are like friends –take a lifetime to make and a moment to lose.

RAM International LLC , a developer of structural analysis and design software, had a very simple API called Programmer’s Interface which accessed some basic data from the RAM Structural System’s flat file database. The challenge though, was that the API could only read the database but not make changes so the API was not used internally because of the extra work to maintain it. After a few years, they decided to build a new API called RAMDataAccess which was a full API that read and wrote to the application’s flat files and could be used by both internal developers and end users. Two very interesting things happened. Internal developers started using the RAMDataAccess because it was so simple to use and the number of users who started using RAMDataAccess almost doubled within months of announcing its availability.

That simple level of high return on investment from the RAMDataAccess API made RAM completely rethink their product strategy from a stand-alone product to a platform that was used to build subsequent products on top of.


So how could an API strategy transform your business? Imagine a product where the users depend on it so much that you would need to pry it out of their dead cold hands. Imagine a product in which other businesses have such a vested interest that they bet their future on it. Imagine a product that is looked at as a starting point – enabling limitless possibilities. Now imagine that the product is yours. Photoshop, AutoCAD, MS Office and LEGO MINDSTORMS did not start as market leaders. They started as underdogs. What got them to where they are was a well-executed and well-crafted plan, and a lot of help from users, third-party developers and even their own internal people who found ways to add value to the product and make it solve specific problems better.

Do some research to figure out what sort of an API best serves your long term objectives and go for it. I look forward some day to seeing your name on the list of market leaders, right next to MS Office, Photoshop and AutoCAD.

'No matter what the name of your company is, most of
the best talent in the world will not work for you.'

Bill Joy


APIs are key elements of a platform competitive strategy. This platform approach acknowledges you cannot do all the development yourself and encourages others to expand your offering with their special focus. Products that follow the platform strategy include operating systems and databases but also Apple's iPhone and Microsoft Office.

Read The Marketing Playbook: Five Battle-Tested Plays for Capturing and Keeping the Lead in Any Market by John Zagula and Rich Tong for more ideas related to using the platform as a competitive strategy.

Emile Kfouri

Emile Kfouri

Emile E. Kfouri is the AEC Solutions Sr. Platform Line Manager at Autodesk Inc. He has 15 years experience in software development and product management with a strong interest in how technology and APIs can help support the long term business objectives of organizations. Emile can be contacted at apiemile@humanscape.com

Looking for the latest in product and data science? Get our articles, webinars and podcasts.