APIs as Products: Governing Principles
As we discussed in yesterday’s post, successful companies already know how to project their business model and shape their market position through non-software business assets. Managing APIs as products means applying the same approach and skills that you already have to them.
Let’s take this discussion a step further by contrasting governing principles commonly associated with traditional “IT projects” versus those suitable for managing “APIs as products” from which tangible changes in team structure, processes, and practices follow.
From “inside out” to “outside in.”
The planning horizon for IT projects is often bounded by “what we have already” and “the resources we have allocated.” Conversely, product planning typically starts by looking at the market and assessing the business upside of winning in new scenarios or the downside of being driven out of others.
“Outside in” leads to a real options approach to investment rather than the discounted cash flow models often applied to IT—assessing “if we have the bases covered to capitalize on opportunities and fight off threats” rather than on ratcheting back to “the least we can do feeling sure net present value is greater than zero.”
Most companies already use this approach in some areas; it's the same discipline of building extra capacity into a factory to take advantage of potential spikes in demand, or holding an option to acquire a company for its intellecutal property if a competitor were to make a breakthrough that you can’t catch up with organically.
From “when we reach a stable, steady state, we shouldn’t change anything” to “if we’re not growing, we’re falling behind.”
If something is driving business upside for you or preventing you from being driven out of a market, then you can count on a race between your company and direct competitors or digital disruptors who want to seize your market share, make your brand less relevant, or hive off your margin.
For most companies, there is a word strongly associated with how they manage their products: “more.” They constantly ask how we are going to drive more share, more satisfaction, more revenue, or more partners. Your APIs are in a race for more.
From “resource re-use is desirable, but failure to do it isn't show-stopping” to “APIs are competing for the critical mass that triggers greatness instead of stagnation or abandonment.”
The relevance of this principle is obvious if you are competing to attract developers or partners beyond the boundaries of your company. Your own internal developer ecosystem, however, can end up either fragmented or coalescing around the resources with the most potential. A Darwinian environment is inescapable in the market, but creating that type of environment for internal APIs has value as well.
We hope these thoughts get you excited about the notion of APIs as products; we broached it as a starting point for further discussion. To that end, the Apigee Institute, Apigee's research and strategy arm, is entering a new phase, aimed at encouraging discussion and taking the discoveries we’ve made and turning them into practices and tools.
We’ll discuss this further in the following post about a new community of practice we're introducing at the Apigee Institute.