Product Management Principles I Learned to Build 80+ Enterprise APIs

CDK Global processes approx $540 billion annually in the automotive industry. When the company decided to open its integration with Modern APIs, the challenge was not technical. It was figuring out which of the hundreds of data points might drive adoption among sales software developers. In three years, the program has shipped more than 80 APIs to the marketplace. Some became important infrastructure. Others have revealed valuable lessons about what business customers need versus what they say they want.

The Vehicle Inventory API has become very important, used by thousands of dealers every day. Customer acquisition revealed that sellers were manually reviewing five different listing sites; the API solved that pain point with sub-200-millisecond response times and sandbox environments that allowed developers to converge in days. In contrast, the earlier API prioritized technical perfection over workflow. It provided complete data extraction with robust error handling, but acceptance was low. The developers had to do a lot of conversion work. The API answered “what data is there” but not “what decision I’m trying to make.”

API marketplace it is expected to reach $49 billion by 2030growing at about 19% per year. Yet many business API programs fail to deliver the intended business results. A survey of 300 IT leaders found that 71% of organizations did not achieve the expected results from their APIs, often due to poor adoption. The gap between building APIs and getting people to actually use them is where many product managers stumble.

It’s a succession of empowerment, not perfection

The instinct when starting an API program is to map every possible data area and build the perfect integration. That approach almost kills programs before they even get started. What works instead is to identify three or four APIs that open up high-value integrations with major partners, and build outward from there. In CDK, prioritization followed a deliberate order: read-only APIs first, then write APIs, then webhooks. Within each category, the ranking is down to revenue attached, number of independent software vendors and vendors using it, complexity, and strategic alignment with leadership priorities.

Starting small with interior projects, it reduces risks and gains knowledge before measuring. The most useful framework treats each API release as a hypothesis about what the ecosystem needs, using discovery metrics to inform what to build next rather than trying to predict everything in advance.

Positioning is a product decision, not a technical one

Setting up is always a high challenge more than 58% of organizations. The temptation is to treat this as a management problem that can be solved through documentation and enforcement. Standardization is effective if it reduces the cognitive burden on developers, not if it satisfies internal compliance checklists.

When multiple teams build APIs with different protocols, integration partners spend more time learning API challenges than building features. The business case for the suspension shines when you count how many engineering partner hours are burned due to inconsistencies. That number is often larger than anyone expects. The CDK synthesis was 20+ years old. Standardized requirements, documentation, request/response formats, and error codes allowed the team to rebuild in one year. The order of priority was important: improve developer experience first, then reduce development time so that subsequent APIs enable scale.

Kong’s API design guidelines get this right: API buyers expect all your APIs to look like they were developed by the same person. The less they have to learn, the more they will accept. Establishing a community of practice across teams to improve standards collaboratively improves buy-in compared to top-down directives.

APIs are the connective tissue of ML systems

The relationship between API design and AI/ML product strategy is becoming harder to ignore. API architectural decisions made over the years constrain or enable what ML teams can accomplish down the line. Embedded stores, storage provisioning models, and training pipelines all rely on clean data access patterns.

Infor’s the AI ​​approach to business demonstrates this with their API Gateway connecting Infor and third-party applications, bringing together data sources in one place that ML models can use. When APIs are designed without considering downstream ML use cases, teams end up building ineffective data pipelines to work around the limits. The costs of those methods of working quietly accumulate until a major ML effort exposes the technical debt. Redesigning the Customer Information API to provide a single source of truth reduced duplicate events from the start. Better source data for customer records means that ML systems using customer lifetime value analysis, propensity modeling, and segmentation have cleaner inputs and improved predictions.

Marketplace Dynamics is not intuitive

Building APIs is straightforward compared to making them available in the marketplace. The B2B ecosystem has some conflicts: business buyers need security reviews, procurement approvals, and integration services. An API that solves a real problem may still fail if the discovery process requires a lot of organizational work.

What motivates market adoption is to reduce the time to start integration. Sandbox environments, working code samples, and documentation assume that developers are more of a time-delayed issue than feature perfection. Successful APIs have usage patterns that are measured in hours, not weeks. Moving from static PDF documents to API documents with sample request/response code and error handling requirements eliminated back-and-forth questions clogging up the support line. Integration-related support tickets are down nearly 30%.

Organizations that treat APIs as products, with dedicated owners responsible for their long-term success, consistently outperform those that view APIs as pipelines. This is true in all cases of consulting, e-commerce, and business software. APIs are how modern companies expose their core capabilities. Self-improvement is a competitive advantage that compounds over time. If APIs like a bunch of repair orders are built for long-term success, apps create a number of deals, which drives more dealers to the platform, which attracts more developers. The platform becomes the default integration layer. With the industry’s shift to AI and API-first mindsets, that consolidation effect is accelerating.