Editor's Pick (1 - 4 of 8)
Transformations in Financial Technologies
The Difficult Road to a More Secure Future
AI becomes "Personal"
Gaining 360 Degree View of Consumers
Mold the technology with NetSuite to Fit the Business Needs
Rick Gemereth, CIO, Lionel LLC
The Force of Mobile and Wireless Technology: Driving Business Innovation, Increasing Productivity & Exceeding Customer Expectations
John Mason, CIO, Bottomline Technologies
VoIP Phone System Brings Exquisite Communications Makeover to MANA Products
George Alexandrou, VP & CIO, Mana Products
Business Continuity and Data Availability
Ed Toner, CIO, State of Nebraska
Why Your API Should Be Your Next Product
By Todd Mezrah, VP, Drawloop Division, Nintex
our API is lot more valuable than you give it credit for. That’s the conclusion I’ve drawn as of late. If all you’re doing is building an API and making it available, you’re selling short what can be a very beneficial offering for your company.
The trick is to treat your API like a product. Design, package and market and support it like a product. This is a substantial shift from how we usually think about API. Usually we treat it like a develop-to-developer sort of thing —a string of code to go along with all the other IT mumbo jumbo that enables business and commercial activity but doesn’t truly participate in those activities, on the same level.
I know this because, until recently, that was our thinking at Drawloop, the company I founded. But now that we’ve shifted our perspective and see our API as something that is every bit as viable, desirable and marketable as any other product, we’re never going back.
A Wider Market
The new API from Drawloop is called DDP API, based on the Dynamic Document Packages (DDPs) used by applications like Salesforce. However, we built the API to allow customers to automatically produce documents with data from any application. So even if you’re using a homemade CRM, with DDP API you can collect data from third-party sources and publish it in several different kinds of common document formats (e.g., Word, Excel, PPT, and PDF).
We built this API because we were looking for ways into a variety of customer ecosystems. And the fascinating thing is, once we had a robust API that achieved that, how much we’ve seen it influence our entire sales approach and messaging. We’re no longer appealing to customers who use one particular application or face a certain set of pain points. Spurred by our API, we’re able to address multiple environments, even those that are highly unique and customized.
Code v. Click
In leveraging our API as a product, we made one choice that I would say really made the difference in making it marketable and effective. We wanted to move our product from a “code” experience to more of a “click” experience, something customers could manage on their own.
If you doubt at all that your API can help grow and scale your business, try looking at it from a customer’s perspective
When you’re sharing your API as unpackaged code, you can expect to be heavily involved in getting customers up and running. You’ll be fielding numerous questions and calls and walking each customer through—what is a very complicated process. The written guide to our API makes our customers more self-sufficient, which they enjoy. It also spares us hours of hands-on assistance, which we are happy to spend elsewhere.
Reaching Your Wider Market
Creating that user-friendly documentation will go a long way toward helping you market your API. Who do you market it to, though? How do you reach out to your new customers?
If your goal is to work in a variety of customer ecosystems, like ours was, then you should seek out thought leaders and representatives of those different ecosystems. Forging those relationships will open doors to fertile distribution opportunities, as your partners build into your API and deploy it into the new ecosystem. From big brands like SAP and Oracle to smaller ones that are experts in the big brand’s technology and systems, you have a slew of potential partners to engage as resellers.
You also have the opportunity to use your API as a springboard into new, collaborative technologies. Drawloop is now doing this with Nintex, the company we recently merged with. Together, we’re doing things neither could do alone. With our API and their technology, we’re creating products to solve problems that, before the merger, weren’t solvable.
What It Takes
I hope the benefits of “productizing” your API are abundantly clear. More than just a standard product that sells, you’re looking at something that can scale, through resellers and joint products, and grow your business dramatically.
To yield those kinds of results, make sure a few things are part of your approach:
1. Make it robust – Drawloop designed our API to offer at least 80 percent of the functionality you can get from our full app. This is important in making it viable in its own right, instead of a second-class substitute.
2. Make it easy for customers – Working with a technical writer to create that operating manual for DDP API was one of the smartest things we did. An API is complex, so to make it flourish as a product you need to make it as simple and accessible as possible.
3. Make it something others can integrate – The OEM potential for an API is extremely rich. An API is perfectly suited to be a component of another company’s offering, and building those partnerships is a huge part of taking your API to market.
As I said in the beginning, it comes down to recognizing the value of what you have. You know, who already recognize how valuable your API is? Its the people who use it. If you doubt that your API can help grow and scale your business, try looking at it from a customer’s perspective. The demand is there—the only question is how you fulfill it.