Industry Insights

Building Developer Ecosystems, Part II: Making It Easy

By Nick Gilbert / Feb 22, 2015

Developer  Ecosystems  Part  Ii Blog

In my last post, I introduced key concepts around building developer ecosystems, an increasingly important strategy that providers are using to encourage software development that complements their core products. The piece, which you can read here, covers the three types of ecosystems—commodity, add-on, and sell-with—and takes a detailed look at add-on ecosystems.

Here, I will dig deeper into how to design and support an ecosystem that makes it easy for developers to participate. When sign up, on-boarding, marketing, pricing, and other essential steps are simple and straightforward, developers will flock to your ecosystem and drive more revenue, both for themselves and for you.

Ease of Participation in the Ecosystem

From the start, a developer program should be designed to reduce friction wherever possible. This means making it as easy as possible for developers to get test accounts and API access, as well as crystal clear documentation with samples. Generally speaking, you want to make these critical elements as self-service as possible; developers are busy, and your ability to grab and hold their attention will be limited. If you make it hard to participate in your ecosystem, you will try developers’ patience and lose them.

You must ensure that your process for developer on-boarding is as good as the sign-up experience for the program as a whole. Some friction most likely won’t drive developers away after they’ve built an add-on product, but the quality of the experience will dictate whether they build the next add-on, especially if the first product doesn't sell as well as they hope.

Overall, the on-boarding experience should be self-service and well-documented, just like the development experience. However, there are some additional key considerations:

  • On-Boarding: What steps do developers need to take to on-board their products? Is integration work required for web services, and if so, how are integrations tested? For downloadable products, what does the upload mechanism look like?
  • Testing: A full sandbox for testing is critical for both you and the developer. You want the developer to test their software as much as possible before they submit it to increase the quality of the add-ons you see. If you can make testing a mandatory step before submission, it is a huge, time-saving bonus.
  • Marketing: How does a developer create a marketing profile? How easy is it to edit and customize the profile to make it attractive and meet the needs of the developer?
  • Pricing: Can you enable the pricing and flexibility developers need to offer plans that make sense for their products?
  • Submission Control: You’re going to need back-end tools to manage all of the add-ons submitted by developers. You should have the ability to see which developers have requested to publish, as well as a sandbox for you to review and test each submission.
  • Lifecycle Management: You need to provide dashboards to enable developers to see how they are selling and who their customers are. You also need to provide tools for developers to manage their product listings, integrations, and uploads on an on-going basis. This will allow them to continuously update their product as they improve it.

Ease of Sales in the Ecosystem

Once your developer program is up and running, what does a developer do next? This is where cloud service brokerage comes into play. Brokerage offers your ecosystem the simplest route to market, giving your end users a single place to find the add-on products they need to make your product the perfect solution for them.

A critical part of the brokerage process is enabling customers to find and purchase products. A marketplace that provides reviews, product profiles, and feature information is a great way to do this. To be most effective, the site should be categorized by relevant function, user persona, and other major categories, but searching for software is the only beginning. Once customers find solutions they want to buy, how do they transact?

It is essential to enable customers to transact on the marketplace. However, to make this process as seamless as possible, you need to be able to accept payment on behalf of the developer. That way, you’ll not only provide a better customer experience, but also get an opportunity to earn margin on the sale. If you don’t allow customers to transact, developers will have to set up their own payment acceptance methods—and all of the infrastructure that goes with it—which creates unacceptable levels of friction.

Even better, you should offer your customers a way to sign in with credentials so they can access payment methods on file (e.g., a credit card) and easily purchase additional items. This not only dramatically reduces the friction for customers and developers alike, but it also makes your core service stickier by making it an anchor for a constellation of services that expand value to your customers.

To drive additional sales, you should consider enabling cross-product bundling. This will allow you to create and merchandise “starter” or promotional packages based on user persona or function. You can use these bundles to increase sales, and also lower the amount of effort customers have to put in to find and consume products that will benefit them.

Your sales team can also play a key role in marketplace transactions. Enabling sales to provision services for your customers allows you to treat your developer ecosystem as a catalog that significantly extends your product footprint. Your sales team will figure out which tools help them close more deals, and your account managers can use these tools to help engage your existing customer base to save at-risk customers.

Finally, you need to consider how you track these sales so you can compensate your sales team, and most importantly, pay the developers. To do this, you need to keep close tabs on what was sold to whom, as well as the revenue shares owed to each party. This can be particularly challenging if you do not have a uniform revenue share rate across your ecosystem.

In the final installment of this series, I’ll explore the two other types of ecosystems, sell-with and commodity. If you have any questions in the meantime, please don’t hesitate to reach out.

Nick Gilbert is the Global Director of Solutions Consulting at AppDirect.