Whats In It For Me(WIFM) in APIs?
When we started the API Program we did so with common tenets which included a self service model, product teams are responsible for the lifecycle of the APIs and for the go to market strategies. Our APIs are for the most part built on human centered design which for us means that any feature request, bug fix or enhancement would have to demonstrated as a direct or indirect request from a customer. The human centered design avoids enhancements being guided by the largest paycheck in the room or “this is how we always do it” scenarios. One of the biggest benefits about designing APIs with a human centered design is that the customer as well as the product teams always knows What’s in For Them.
Call it a culture shift but when building an API program built on self service means you pulled away from the concept of commonality in a big way. You are guiding your own ship, you and decide what direction the ships sails. One of the biggest challenges is WIFM versus Whats In It For Them(WIFT) appears when teams outside of your product team want help or your service to perform a different function. Some of examples of this are reasoning is governance, security standards or deployments.
Finding a balance is difficult because on the one hand the teams asking for help have a business driver or need. A product team needs to find measures to identify the need of the customer versus the need of the internal business operations.
