Lean, API and IoT are probably the most hyped terms right now in our industry. While I tend to to explore the latter two, I would like to balance it by talking about the former: Lean and API.

Why Lean and why API?

Lets talk about Lean first. You have probably heard about or even read Lean Startup from Eric Ries. It sparked a whole cottage industry of Lean publications, like Lean Analytics, Lean UX and the probably most widly missunderstood concept of a Minimal Viable Product (MVP). But only a few venture beyond that and read the 4 Steps to the Epiphany from Steve Blank. In that he develops a business process for startups called ‘Customer Development’ for finding ‘Problem Solution’ and ‘Product Market’ fit. Even fewer venture back to the origins of the “Lean” concept, the Toyota Lean Production System with its emphasize on pull over push and ever decreasing batch size towards One-Piece-Flow manufacturing. And this does not even include Clayton Christensens ‘Theory of Disruptive Innovation’ in [The Innovators Dilemma] (http://www.amazon.com/Innovators-Dilemma-Revolutionary-Change-Business/dp/0062060244) and Rita McGrath’s concept of ‘Discovery-driven Planning’ in Discovery Driven Growth

But the purpose of this blog is not to provide a comprehensive reading list around Lean and Discovery-driven Business Strategies but to explore if and how it can be applied to API Design. If you are curious and want to know more about the books mentioned I suggest you head over to my launchd.de blog. And for your next long haul flight, you mighy want to consider starting with the The Goal for some truely novel-like ‘business’ reading.

Before I explore how Lean and API Design come together let me first make a confession - I got an MBA a couple of years back. I know that this is not going to win me any browny points and I still prefer much more to code over spreadsheets, but it goes some way to explain why I think that business and API are joined by the hip. The business value of APIs does not come from “being an API” but by providing access to a business asset or service. APIs are a technical means to do (more) business. From this follows that the API design and implementation need to take into consideration the intended business outcome. Which in turn mans that you have to first get clarity on the business goals before starting to implement. Unfortunatly - in my experience - most of us on the technical side are not equipped to talk to business side of the house (and neither are they). This is why went back and got an MBA - so that I could learn to speak with “them” and build better products.

Starting with Toyota’s Lean Product Development process, I began to see approaches and tools which could help to bridge the semantic gap between the technical and business sides, some of which I hope you will find useful and which I want to introduce in subsequent posts to our API Design practice.

I will start with Alexander Osterwalder’s Business Model Canvas. To get a first impression I suggest that you read at Mark Boyds post on Programmable Web. He is using the Business Model Canvas to analysize Walgreen’s Quick Print API. Also check out my presentation on Lean API Strategy at the recent API Days in Berlin.