Olaf Stelter - Leveraging API Docs and Tools at Mercedes-Benz /developers

Enabling innovative business models by working with different kinds of data

Launched a technical platform 4 years ago and the work started 2 years before that. Then the journey continued:

• First set of Products become available
• API Ecosystem is established
• Launch of experimental connected vehicle
• Launch of 5 vehicle data products: the products really got access to the cars
• First Mercedes Benz Mobile SDK
• BYOCAR Mercedes Benz APIs: developers & OS communities gain access for free as long as they access their own car, a lot of engagement and innovations were seen, mostly regarding home automation
• Launch of B2B APIs for fleets

Three main pillars of Mercedes Benz data:

• Marketing data: car configurations, descriptions, images, equipment
• Vehicle data: everything related to the connected cars
• Anonymized data: mainly in the mobility area, SRTI is a possible initiative to improve world safety to set up the right standards - like PSD2 in the banking sector

There are more audiences than just developers

Traditional users: developers, code focus team
Increasing number of groups of audiences which are business related users

The devportal needs another layer to provide relevant information to guide the more and more diverse audiences (business users, stakeholders, enterprise), starting from their perspective, to the product they need, and then to technical details.

The documentation on the devportal is a way of communication with your audience.

Handle the growing number of API products

The portal and the documentation has to reflect the growing and diverse audiences to allow them to run through the catalog and identify the product that are relevant for them.

Must handle the growth of products: need to restructure the entry points to the data catalog:

• At the beginning there were only 3 APIs, easy to overview and handle
• Now there are 15 products in the API catalog + other 15 ones to dedicated customers (not available for everyone on the portal) + lot of new upcoming products

Set focused increase on parts of portal maturity

The Devportal Awards categories can help to analyze the portal and to set the focus for the next steps.
Decided to focus on Onboarding and API Reference docs in 2020, to help new developers and customers onboard as fast as possible, start using products and set up new business solutions and get their job done as fast as possible.

“Evaluate the different DevPortal Awards categories and depending on where you are, approaching the next step on maturity, decide on where to set your focus to further develop the devportal.”

Product documentation is essential in leveraging business value and targeting your audiences

Every user group needs their type of docs.

• The structure of the documentation has to follow the needs of the different target groups and it has to be clear:
• Tiles in the catalog help to identify the relevant product
• Product description and more detailed information about the features and capabilities
• Technical docs and API specification
• Pricing information with the available packages
• Additional success stories and use cases

Guidance to manage the full API product lifecycle

Product onboarding guide and tools set guidance for successful product launch. There is one central team responsible for the platform and the operations, also being "customer success managers" for the many internal API product managers.

Internal API Product managers are responsible for their own internal applications and APIs, but most of them have never before launched a public API/product.

Split up the process into three phases (pillars):

• Preparation (product onboarding)
• Publishing with the final review and the launch of the product
• Product lifecycle with maintenance and customer support

Product onboarding guide to assist PMs through various technical, financial, legal, etc, steps. It takes several weeks up to months until everything is ready and well approved and the API product can get launched.

Three tools materializing the pillars:

• Confluence: to collect all the information and review
• Drupal: manually copied content from Confluence to the CMS
• Portal: the product environment with polished content and information

This process is regularly reviewed for pain points and adjusted if needed.

Tools and best practices provide guidance to manage product lifecycle

Confluence and Drupal supports iterative content collection and pre-publishing view
Approved content readiness leads to product publishing and portal visibility

Moving between tools reached pain point, currently optimizing the workflow for scaling.

Lessons learned and best practices to manage API products

• Business Development Portal is still named (API) Developer Portal, but it’s about creating and enabling business
• Business building blocks are still named APIs, but it’s not about the interface connecting to a system, it’s about a business building block, something you can use to build something new. Be aware of the value proposition of your product, what can the customers do with it.
• Business documentation becomes more important than API specification
• Process of collaborative content creation needs iterative solutions to mature: multiple stakeholders collaborate until everything is well done, the process and how you collaborate internally to execute has to be often adjusted to become really effective
• Upcoming digital marketplaces extend product visibility: will you operate just your own devportal or will you promote and sell your products additionally on digital marketplaces
• Offering additional business solutions leverages API adoption