Like any product, creating a solid piece of software requires a lot of people focusing on doing what they’re really good at. Product managers focus on what the market wants and builds a list of requirements to deliver on that; developers create the product, refine it, add requirements and ensure it’s stable; a marketing team ensures that the intended audience is aware of the product and has the opportunity to try it. The ultimate goal is to provide something that customers want and will pay for. In the software world, with so many choices and so many narrowly defined solutions, it’s a huge challenge to predict customers’ tastes and deliver accordingly. There are also so many different ways to slice and dice a product, and a team of developers can only implement so many features. But at the end of the day, you’re always going to be bound by the aggregate skill level, perspective and capacity of the people on your team.
If your business is making hamburger buns, then there’s not a huge threat – there just aren’t that many different ways to deliver a successful bun. But if your business is software, then you may discover that a competing product is killing yours because it’s got just merely a slight advantage. That little advantage is enough to render your product obsolete.
But we don’t sell hamburger buns for a living. Our business is making software that enables the development of great software products and we know that in software, we have a huge advantage over any other type of market, and it’s this: we can get others to do our work for us. I’m not talking about slyly coaxing people to give us their ideas. Quite on the contrary, there exists a phenomenon unique in the software world – the inherent nature of the 1′s and 0′s that constitute the foundation of our product can be made easily available to others who think they can do something beyond what that piece of software was originally intended for. And there are a ton of really smart, skillful developers who make it their business to take that software and connect it to their own software, thus creating a solution that previously didn’t exist. And without asking for any more time of product managers or marketing experts, we find that our product becomes more valuable because of what it enables, and the products of these developers become more viable because they can tie it into our product.
The best, most efficient and effective way to do this is with APIs. APIs have been used for quite a while, but with the advent of more ever-present Web services and cloud-based applications, they truly have become the one of the most crucial elements in the process of getting your app or service to be more robust and ultimately into the hands of more customers. The API makes your product more attractive not just to customers, but to their customers as well. That’s the network effect in action, and indeed, it builds a more interesting marketplace for your customers.
But an API in and of itself isn’t worth much unless you’ve figured out your purpose – what’s your market, who are your users, what holes are you filling, and what business are you willing to let others do for you. This is where you have to start in order to develop an effective API strategy. It’s strategic, but it’s also part of an overall philosophy that frees you to focus on what you’re best at, while letting your ecosystem of partners and developers contribute their own strengths. These developers, irrespective of where they come from, are people who identify your product as an opportunity. You provide the framework and foundation, and they provide their insight and skills. From there, the world benefits from a better product.
To be effective at creating this type of environment where developers are free (and encouraged) to participate in your products’ development; you need to begin by ensuring that you have roadmap, and that you provide that roadmap to your community of developers. You can start by thinking about these things:
Who is my intended audience?: Is there a specific platform they develop on? Should they have expertise in a particular vertical? What skill level should they have? The answers to these questions will inform the essence of your developer community. Once you know who your audience is, you’ll be equipped to find them where they hang out (other online developer communities, social media, etc), and the type of support material and documentation you need to provide.
What do I want my API to do?: This is an important consideration; in fact, it may be the most important consideration. Is your company totally open and willing to let others get close to your product? Or do you prefer to give developers limited access and have them focus on smaller add-ons to your product? This also is important because it will define your “brand” to developers and explain to them the type of company you are.
What direction will I give?: What kind of direction are you going to give developers – should we enable the API to allow them to do whatever they want? If so, then we should be prepared for the standard stuff: add-ons like search, content streams, front-end customizations. Nothing wrong with any of that, but we may not see any major changes. On the other hand, we could create a product roadmap and encourage them to fill holes and truly enhance our product or service. If we steer them in this way, then we want to be more specific about where we see opportunity, and how they can benefit from that opportunity.
This is really just the starting point for a successful API community, but it’s crucial. At SOA Software, we really do think that your API is your brand, and you’ll find that you’ll be so much more successful with it if you define a strategy for your API. Learn about Atmosphere, our family of API development and management solutions that will enable you to be successful with creating and managing your API strategy – http://www.soa.com/atmosphere/ .