Product Management Principles I Learned Building 80+ Enterprise APIs
CDK Global processes approximately $540 billion annually in automotive commerce. When the company decided to open its integrations through Modern APIs, the challenge wasn’t technical. It was figuring out which of the hundreds of possible data endpoints would actually drive adoption among dealership software integrators. Over three years, the program shipped more than 80 APIs to the marketplace. Some became critical infrastructure. Others revealed expensive lessons about what enterprise customers actually need versus what they say they want.
The Vehicle Inventory API became mission-critical, used by thousands of dealerships daily. Customer discovery revealed dealers were manually updating five different listing sites; the API solved that pain point with sub-200-millisecond response times and sandbox environments that let developers integrate in days. In contrast, an early API prioritized technical completeness over workflow. It offered comprehensive data extraction with robust error handling, but adoption flatlined. Developers had to do significant transformation work. The API answered “what data exists” but not “what decision am I trying to make.”
The API marketplace market is projected to reach $49 billion by 2030, growing at nearly 19% annually. Yet most enterprise API programs fail to deliver planned business results. A survey of 300 IT leaders found that 71% of organizations did not achieve expected outcomes from their APIs, often due to poor adoption. The gap between building APIs and getting people to actually use them is where most product managers stumble.
Sequence for leverage, not completeness
The instinct when starting an API program is to map every possible data point and build comprehensive coverage. That approach nearly kills initiatives before they launch. What works instead is identifying the three or four APIs that unlock the highest-value integrations for the largest partners, then building outward from there. At CDK, prioritization followed a deliberate sequence: read-only APIs first, then writeback APIs, then webhooks. Within each category, ranking came down to revenue attached, number of independent software vendors and dealers using it, complexity, and strategic alignment with leadership priorities.
Starting small with internal projects, lowers risks and gains experience before scaling. The more useful frame is treating each API release as a hypothesis about what the ecosystem needs, using adoption metrics to inform what to build next rather than trying to predict everything upfront.
Standardization is a product decision, not a technical one
Standardization remains a top challenge for more than 58% of organizations. The temptation is to treat this as a governance problem solvable through documentation and enforcement. Standardization succeeds when it reduces cognitive load for developers, not when it satisfies internal compliance checklists.
When multiple teams build APIs with different conventions, integration partners spend more time learning API quirks than building features. The business case for standardization crystallizes when you calculate how many partner engineering hours get burned through inconsistency. That number is usually larger than anyone expects. CDK’s integrations were 20+ years old. Standardized requirements, documentation, request/response formats, and error codes allowed the team to rebuild them in one year. The priority order mattered: improve developer experience first, then reduce development time for subsequent APIs to enable scale.
Kong’s API design guidelines capture this well: API consumers expect all your APIs to look like they were developed by the same person. The less they have to learn, the more they will adopt. Establishing a community of practice across teams to evolve standards collaboratively improves buy-in compared to top-down mandates.
APIs are the connective tissue for ML systems
The relationship between API design and AI/ML product strategy is becoming impossible to ignore. API architecture decisions made years earlier constrain or enable what ML teams can accomplish down the line. Feature stores, model serving endpoints, and training pipelines all depend on clean data access patterns.
Infor’s approach to enterprise AI illustrates this with their API Gateway connects both Infor and third-party applications, tying data sources into a single location that ML models can consume. When APIs are designed without considering downstream ML use cases, teams end up building brittle data pipelines to work around limitations. The cost of those workarounds accumulates quietly until a major ML initiative exposes the technical debt. Redesigning the Customer Info API to establish a single source of truth reduced duplicate instances from the start. Better source data for customer records meant ML systems running customer lifetime value analysis, propensity modeling, and segmentation had cleaner inputs and improved predictions.
Marketplace dynamics are not intuitive
Building APIs is straightforward compared to getting them adopted in a marketplace. B2B ecosystems have particular friction: enterprise buyers need security reviews, procurement approvals, and integration resources. An API that solves a real problem can still fail if the adoption path requires too much organizational overhead.
What drives adoption in marketplaces is reducing time-to-first-integration. Sandbox environments, working code samples, and documentation that assumes developers are time-constrained matter more than feature completeness. The APIs that succeed have deployment paths measured in hours, not weeks. Moving from static PDF documentation to interactive API docs with sample request/response code and error handling requirements eliminated back-and-forth questions clogging the support queue. Support tickets related to integration dropped by about 30%.
Organizations that treat APIs as products, with dedicated owners responsible for their long-term success, consistently outperform those that view APIs as technical plumbing. This holds true across consulting, e-commerce, and enterprise software contexts. APIs are how modern companies expose their core capabilities. Getting them right is a competitive advantage that compounds over time. When APIs like repair order bundles are built for long-term success, applications create value for dealerships, which drives more dealerships to the platform, which attracts more developers. The platform becomes the default integration layer. With the industry shift to AI and API-first mindsets, that compounding effect accelerates.
The post Product Management Principles I Learned Building 80+ Enterprise APIs appeared first on SD Times.
Tech Developers
No comments