Now you’re creating a set of tools to solve a problem that nobody knows about, for people you haven’t met.
For our latest “What I’ve Learned…” interview at OpenChannel, we sat down with Mike Amundsen, internationally known author and speaker who works with leading companies to help them capitalize on the opportunities provided by APIs, Microservices, and Digital Transformation. He recently joined Mulesoft as API Strategy Advisor, and prior served as the Director or API Architecture for the API Academy at CA Technologies, and Principal API Architect at Layer 7. He has authored numerous books including “RESTful Web Clients”, and co-authored “Microservice Architecture”, and his latest book “Design and Build Great APIs” for Pragmatic Publishing is scheduled for release in late 2019. Mike has been a leader in the API community for years, he sat down with us to share what he’s learned along the way….
OpenChannel: From this post, you said monetizing APIs is about “reaching outside an organization, but that doesn’t just mean charging for you APIs…It’s about creating new businesses and partnerships”. Do you see companies struggling with this?
Mike Amundsen: Yes, It’s not that they don’t want to do it, but it means changing what they do. Organizations aren’t quite prepared for this kind of change. It’s about creating a platform. In gaming it’s called a “Possibility Space”.
That means you don’t create a space where everyone behaves the same way. You create a space where many things can happen. It’s important to design in a way that people do things that they want.
When you’re at this stage with APIs, you’re creating more complex possibility spaces where developers can play and do what they want. You’re helping people solve their problems, not yours.
Amazon, Microsoft, or Google are very good at creating these possibility spaces. The way they design APIs, the data models, and other things are to solve other people’s problems.
OC: Then what can a company do to increase the chances of success when creating new partnerships with their APIs?
MA: They have to know what their developers’ behaviors are. What are they trying to solve? What challenges do they have?
You have to spend time figuring out your audience. When I work with companies developing their API platform and marketplace, one of the things we do is talk to developers. We would ask things like “How much time do you spend on this every day? Walk us through the process of what you do.” To increase your success, you need to know your audience better.
OC: Every API and platform has to balance both business and technical needs to be successful. How do you think about balancing those two things?
MA: The phrase that I use is, “Now you’re creating a set of tools to solve a problem that nobody knows about, for people you haven’t met”.
You have to be a leader in a technical sense about what’s going to happen soon. Then you have to build APIs and platform where others can experiment. Simon Wardley has the framework of pioneers, settlers, and town planners. Be a pioneer.
You have to build a system where experiments can be done that don’t kill the system. Where you can change the system over time without hurting your customers. You need to be able to release new versions without hurting anybody.
I live in the Cincinnati, Ohio area and we have an amazing product culture through Procter & Gamble. They’re a great example from the business side of things. Their only job is to figure out what’s driving people nuts and solve those problems. Then they experimenting with products, packaging, and have a marketing and business arm that makes sure we hear about it, because we are the ones with the problem that needs to be solved.
It makes no sense to have great technical systems that build great products if you don’t connect with the customer.
OC: Often those of us in technology don’t want to learn from more traditional enterprises like P&G, but there are lessons to learn.
MA: Their portfolio of CPG (Consumer Packaged Goods) is always getting better. I think people are always amazed, saying “Wait, Procter & Gamble has all these brands that I actually like?” I think there are lots of lessons for us that we could learn from “non-tech” companies.
It’s important to remember from the technology side, that nobody actually cares about the APIs we build. They care about the problem they’re trying to solve. It’s Clayton Christensen’s, Jobs to be Done.
OC: What should companies focus on when creating an API or developer app marketplace?
MA: When you look at examples like Salesforce or even Netflix and Amazon, we’re talking about companies that are truly global and solving problems at a global level.
Many customers don’t need to solve problems at that scale yet. Like any kind of system, things that work at one level may not work at the next.
So companies don’t have to copy Salesforce or Netflix directly. I encourage companies to use those examples as a model to learn from, but not to copy every aspect.
I recommend that companies find their secret sauce, that they find the thing they’re amazing at and then begin building APIs around that in increments, step-by-step.
I have a lot of customers that try to do a big-bang approach. They hire new staff, get excited and say “We’re all going to be agile by Friday.” Of course, it never works like that.
I quote Edward Deming, a statistician that worked with Japan after World War II to rebuild manufacturing. One of Deming’s great quotes is, “The job of a manager is to improve the system”. That’s interesting because it doesn’t say improve the product or improve the staff. It’s the system. So the focus on the system to allowing smart people and developers to make great products.
OC: What are some of the biggest mistakes you see companies making?
MA: The general rule I tell folks is – The wider your audience, the more generic your design. The more specific you are in solving problems, the less flexibility you have.
We build APIs to solve one problem. Then somebody else says, “We need an API to solve a similar (but not the same) problem”. So we build another API and you have two APIs that are similar, and this happens over and over again.
You get an explosion of similar APIs, then somebody says, “Why can’t we all use the same API?”. Then companies try to create one canonical model, data model, or object model – but that’s way too specific.
As your ecosystem grow and you have more and more people using your platform, you have to make your platform and APIs more general rather than more specific. One of the best ways to do that is to focus on managing a vocabulary or a glossary of terms rather than an object model, functional model, or data model.
OC: How does a platform instill trust into their third-party developers?
MA: Building trust is really, really important.
Developer’s have limited time and need to know that if they make a commitment to your tooling or platform, that they will get a reward back and it will make their life easier
They need to know they can count on you – that your API’s are not going away, that it’s actually going to get better and that a company will listen to feedback.
A lot of my customers are good at asking developers for feedback but are not very good at what I call the “feedback-to-feature loop”. Meaning, how long does it take from the time they get feedback until it turns into a feature? And making that as short as possible is an important way to build trust.
Also, you should never ever make a developer rework anything. If you want to add some new features, improve your API, then do it in a way that doesn’t break anything. Usually, that means that you’re running parallel versions or parallel examples.
OC: What companies and platforms or ecosystems do you admire?
MA:: One of the reasons I love Twilio is, they went all-in on developer first. They pay attention to their developers and how to make life easier for them. Their product, training programs and onboarding process are all focused on developers.
I remember years ago, they had a campaign was directed at decision-makers that said “Ask Your Developer”, which I thought was brilliant.
OC: You recently joined Mulesoft, what appealed to you about the company?
MA: MuleSoft is now part of the Salesforce ecosystem and Salesforce is this company that taught all of us, now 20 years ago, the Software as a Service model. It’s an amazing company and they follow a lot of the things we’ve been talking about.
MuleSoft is the API-end of what Salesforce wants to be doing. Mulesoft has this great “anything is available from anywhere” approach. It’s one of the places where I think you could start to see a strong ecosystem develop.
One of the first things I did was spend a week at Salesforce Tower with MuleSoft staff learning about how they build APIs and tools, how they productize and market their technology and learning more about these kinds of things like marketplaces.
OC: What’s something you’re good at or love to do that most people don’t know.
MA: I don’t know about the “good-at” part, but most people don’t know that in a previous life I was a professional musician.
I have two college degrees in music theory and composition. They’re not in computing. So my whole life as I went through college and after was as a musician.
The idea of playing music in a group is – you have this general outline and you play together. You learn from each other and each time it’s slightly different. That’s possibility space. That’s gaming. That’s really what drives all the kind of work that I do.
How do we get a bunch of people to play as a group, together, but do it in a way that’s unique for them every single time? So the music still drives me every day.