DMA do's and don'ts for product teams

Do not review a DMA change as a generic platform policy issue. The obligations attach to the gatekeeper's listed core platform services, and many checks depend on whether the feature affects business users, end users, advertisers, publishers, developers, search providers, hardware providers or messaging providers.

For each release, write down the designated core platform service, the user journey being changed, the data flows touched, the default or ranking systems touched, the business terms changed, and whether the change creates a new interface, API, request path or restriction.

Article 5 contains obligations that product teams can often test directly in flows, terms and data-processing rules. The practical product question is whether a release blocks business users from reaching customers, forces use of a gatekeeper service, combines personal data without the required consent choice, or withholds advertising price, fee, remuneration or metric information that the DMA says must be provided on request.

Treat Article 5 issues as release blockers when the change adds friction to off-platform offers, removes an external-contract path, bundles login, browser, payment, identification or another core platform service as a condition of access, or changes consent prompting for personal-data combination or cross-use.

Article 6 is where many product changes need engineering and data-governance evidence. A release that touches ranking, app-store access, default settings, uninstallability, switching, advertising measurement, data portability, business-user data access, search data access or termination conditions should have an Article 6 review before launch.

The recurring don't is using platform control to advantage the gatekeeper's own services. Product teams should test whether the change gives equal technical access where required, makes switching or third-party installation practical, and avoids using non-public business-user data in competition with those business users.

For number-independent interpersonal communications services, Article 7 requires interoperability of listed basic functionalities on request and free of charge, while preserving the level of security, including end-to-end encryption where applicable. For operating systems and virtual assistants, Article 6(7) separately requires effective interoperability with the same hardware and software features available to the gatekeeper's own services or hardware.

Product teams should treat interoperability as a product surface, not only a legal response. The release package should include request intake, eligibility criteria, technical documentation, API behavior, security review, developer communications, rejection reasons, escalation paths and maintenance plans.

Article 13 matters because a product can technically implement an Article 5, 6 or 7 measure while undermining it through design, contractual terms, commercial incentives, API limits or degraded quality. Product teams should review whether the release makes a DMA right harder to exercise in practice.

This review should happen after the obligation-by-obligation check and before launch approval. The reviewer should compare the user or business-user path before and after the change, including settings, copy, warnings, eligibility rules, fee changes, API limits, latency, documentation, support and dispute paths.

A DMA release is not ready when the feature ships; it is ready when the compliance evidence can be found, explained and reused in the gatekeeper's Article 11 compliance report. The Commission template asks for separate information for each core platform service and each applicable Article 5 to 7 obligation.

Build the evidence pack during product development. Waiting until report drafting usually loses the details that matter most: baseline behavior, implementation dates, engineering changes, UI paths, terms changes, consultation inputs, alternatives considered, security justifications, testing results and effectiveness indicators.