DMA do's and don'ts for product teams

Review a DMA change against the gatekeeper's listed core platform service and the affected user group. The applicable 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.

A gatekeeper's release process should stop a launch when the team cannot resolve an applicable Article 5 issue, such as added friction for off-platform offers, removal of an external-contract path, a prohibited tying condition, or a consent design that permits personal-data combination or cross-use without the choice Article 5(2) requires. This is a recommended internal control; the DMA states the underlying obligations, not a product-release approval procedure.

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 a number-independent interpersonal communications service listed in a designation decision, Article 7 requires the listed basic functionalities to be interoperable on request and free of charge, while preserving the gatekeeper's security level, including end-to-end encryption where applicable. The timetable is staged: one-to-one text and attached-file sharing follows listing and falls within the general six-month Article 3(10) compliance period; group text and attached-file sharing is due within two years of designation; and the listed voice and video calls are due within four years, where the gatekeeper offers those functions to its own end users. Article 6(7) separately covers access to operating-system, virtual-assistant, hardware, and software features in the circumstances stated there.

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 gatekeeper should not approve a DMA-sensitive release until the compliance evidence can be found, explained, and reused in its Article 11 compliance report. This is an internal-control recommendation. Article 11 requires the 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.