In this episode, Mike and Matt are joined by special guest Stephen Fishman, Regional Vice President of Customer Success Architecture at MuleSoft and longtime API product expert. Stephen shares insights on product-oriented approaches to API design, development, and lifecycle management. Topics range from API discoverability to launch strategies to a relentless focus on API consumers. Have a listen here:
The following is a brief summary of the podcast:
Tip #1: Your API must be found before it can be consumed
In response to Matt’s question about what has changed most in the API economy in the last 10 years, Stephen talks about API discoverability. He recounts old technologies like UDDI that attempted to provide machine discoverability for APIs, and how the industry has matured to offer marketplaces for human discovery of APIs. Mike mentions his fascination with API discovery, and asks Stephen what is especially new. Stephen feels the big change is the business view of developers. In the past, business people might “throw the nerds in the closet” and let them work, but now developers’ time is coveted. APIs are seen as a vehicle of business value, with developers needed to realize that value. Increasing standardization has also paved the way for greater discoverability and interoperability. With the standardization of API protocols, discoverability has become the “long pole in the tent.”
Tip #2: Think about your API consumers’ multiple personas
Matt asks Stephen his thoughts on the concept of APIs as products, which leads Stephen to say that product thinking is what has evolved the least in the API economy. He compares the API-as-a-product concept to DevOps, which took years to be fully absorbed into the consciousness of organizations. One of the challenges is that APIs are hard to visualize. He cites Alan Cooper as both an early thinker on APIs and a pioneer in thinking of software developers as product consumers. The Cooper shoutout is echoed by Mike. Stephen also talks about the need for product management and software engineering to find a common ground in order to establish API product management.
Mike then asks Stephen about lessons on identifying, attracting, and managing API consumers. Stephen points out that there are multiple personas of API consumers. There are two primary consumer types: buyers (business people) and developers. Whereas the developer is the direct user interacting with the API, the buyer is the “patron” of the work. Both personas must be catered to in order to create product pull through. API providers must then create products that have compelling business value for the buyer, but also have coherence and intuitiveness that allow developers to achieve their optimal state of flow. Matt likens these product attributes to “usefulness” for the buyer and “usability” for the developer and asks Stephen for examples of API product companies that are delivering both effectively. Stephen cites Twilio as a great example and notes how they reduce complexity for buyers by aggregating back-end services while reducing complexity for developers through highly usable interface design and purposeful documentation and tooling. Mike relates this to the idea of value exchange. In describing how API providers can market the developer appeal of their products to business people, Stephen comes up with the best quote of the podcast: “It’s almost like they’re selling educational toys to parents. Look at how much fun your child will have! Look at how much they’ll learn!” Mike and Matt both applaud the comparison. Matt underlines the importance of knowing how each consumer type fits into an API provider’s business model, and Stephen adds the importance of the provider knowing how they fit into the consumer’s business model as well.
Tip #3: Don’t assume your non-digital customers will automatically become your API consumers
In the final section of the podcast, Matt asks Stephen about one of his main focus areas: API monetization. Stephen points out that a common misstep for organizations who are new to API products is assuming you can just charge money for use of your API and you’re done. Harkening back to Twilio, he points out that even though they are a terrific example for a number of API product practices, they are fairly unique in being such a successful company whose primary products are APIs. Most organizations getting into the API space are established players outside of the digital economy with existing customer bases. In spite of this, it’s important for these companies to recognize they will be selling to new customers or selling digital products to their existing customers for the first time. They must consider their “brand elasticity” to test whether their customers will see them as digital product providers. Stephen has seen many companies underestimate how much foundational work is needed to get a digital business model up and running. He sees APIs as primarily a channel play, requiring investment and oversight to ensure consumer trust and brand permission are established. The API cannot be siloed from other value exchanges offered to consumers. Mike backs up these points, giving the example of how a steel producer cannot assume it can sell data about steel production to the same customer base. Matt notes the linkage between this thinking and Clayton Christensen’s “jobs to be done” approach.
Stephen cites BMW as an example of how a company can extend its core business effectively into the digital ecosystem by demonstrating unique value. He notes the contention in the automotive industry around data ownership. Drivers produce the data, but it is collected by the auto manufacturers. In spite of this, BMW has been able to provide high-value analytics around the driver data based on their experience in fleet management, and translate that into digital products that are sold back to the same drivers who produce the data. It’s a great example of establishing credibility through value creation. Impressed with this example, Matt sees value creation through data as a whole other podcast topic.
To close this episode, Matt asks Stephen about the role of his Customer Success Architecture organization. Stephen describes Customer Success Architects as a shared resource. Some assignments are for bigger customers, but they also help all customers connect the dots everywhere from low-level technical issues, technology introduction, and cloud readiness. Their mantra is teaching customers how to fish, helping them to stand up, and manage MuleSoft’s Anypoint Platform. Over time, they help customers get the most out of the platform, taking a holistic approach that even includes organizational advice. This context segues into Stephen’s parting thoughts. APIs are a product that manifests as a service: “The material of service design is organizations.” Connecting the back office can have value, but maximum value comes from transforming the organization, especially having product and technology teams work together in a shared domain, collaboratively. Shared ownership is fundamental and requires both customers seeing you differently, and you seeing yourself differently.
Hope you enjoy this episode! Follow the podcast on SoundCloud or subscribe to our newsletter above to get summaries of the episodes.
