A New Chapter: Compliance & Risks is now Adherent. Read more.

This blog was originally posted on 12th September, 2026. Further regulatory developments may have occurred after publication. To keep up-to-date with the latest compliance news, sign up to our newsletter.

THIS BLOG WAS WRITTEN BY THE ADHERENT MARKETING TEAM TO INFORM AND ENGAGE. HOWEVER, COMPLEX REGULATORY QUESTIONS REQUIRE SPECIALIST KNOWLEDGE. TO GET ACCURATE, EXPERT ANSWERS, PLEASE CLICK ASK AN EXPERT.


Most attempts to improve product compliance operations fail because they start too big. The organizations that succeed begin with a single product family, a small number of priority markets, and one high-friction process, then prove a repeatable model before scaling it. Adherent’s playbook sets out that approach as three thirty-day phases, with a leadership alignment step before day one that determines whether the rest of it holds.

Compliance improvement programmes tend to arrive with a great deal of ambition and very little scope. Every product line, every market, every process, all at once, usually accompanied by a technology decision made before anyone has agreed what is actually broken.

This article is adapted from Adherent’s playbook, The Ultimate Product Compliance Playbook. Companion articles cover the five practices high-performing compliance teams use and the metrics that actually matter. This piece is about sequencing: what to do in the first ninety days, and in what order.

Transforming compliance operations does not begin with an enterprise-wide programme. The most successful companies start with a single product family, a small number of priority markets, and one high-friction process.

That narrowness is deliberate rather than cautious. A single product family is small enough that you can change how the work happens without renegotiating every existing process, and large enough that what you learn transfers. It gives you a baseline you can actually measure, a group of people who can be genuinely aligned rather than merely informed, and a result you can point to when you ask for the budget to go wider.

The objective is not to solve everything at once. It is to establish a repeatable operating model that can be scaled across the business.

Ninety days matters for the same reason. It is long enough to change how a team works and short enough that leadership attention has not moved elsewhere before you have anything to show.

Understanding your current operating model is only the first step. Before the ninety days begin, identify the areas creating the greatest operational friction and get leadership agreed on where to focus first, because a pilot that leadership has not agreed to is a pilot nobody acts on at day 90.

The playbook sets out nine questions in three groups. They are worth working through with product, engineering and business leadership in the room, not just compliance.

Align on business priorities

  • Which compliance challenges create the greatest business risk today?
  • Where do compliance issues most often delay product delivery or market access?
  • Which improvements would have the greatest impact on customers, revenue, or operational efficiency?

Align on the operating model

  • Which of the five practices represents our biggest opportunity?
  • Where are teams working from different information or disconnected processes?
  • Which manual activities consume the most expert time today?

Align on next steps

  • Which improvement could realistically be achieved in the next 90 days?
  • What capabilities, technology, or process changes would be required?
  • How will we measure business impact?

The answers to the second group usually point directly at your scope. If teams are working from different interpretations of the same requirement, the pilot is about establishing one regulatory baseline. If experts are spending their time gathering rather than judging, it is about what gets automated. The playbook’s twenty-statement scorecard is a faster route to the same answer if you want to arrive at the conversation with a view already formed.

The first month is about definition rather than change. Define the compliance workflow for your chosen product family, and be specific about four things:

  • Launch gates. At which points in development does compliance have to have answered something before the process continues?
  • Evidence requirements. What evidence does each product and market need, and who is responsible for producing it?
  • Escalation paths. Where do ambiguous regulatory decisions go, and who resolves them?
  • Success metrics. Identify two or three to track from the outset.

Choosing metrics in month one rather than month three is the step most often skipped, and skipping it is why so many compliance projects cannot demonstrate anything at the end. If you have no baseline, any improvement you deliver is unprovable. Pick a small number, measure them before you change anything, and keep measuring the same things throughout.

What “done” looks like at day 30 is a written workflow that the product and engineering teams involved recognise as an accurate description of how the work will now happen, and a baseline you have actually recorded.

The second month is where the operating model starts to change. Standardize how regulatory requirements are documented and communicated, so that the same requirement reaching product, engineering and sourcing arrives in the same form and means the same thing.

Measure baseline cycle time and time to evidence. Cycle time tells you how long it takes to move from a regulatory change to a decision the business can act on. Time to evidence tells you how long it takes to produce complete, traceable documentation when someone asks. Both are leading indicators, and both are usually worse than teams expect when measured properly for the first time.

Then begin building a reusable library of regulatory interpretations and known positions that can be applied across products and markets. This is the part that compounds. The first time a team interprets a requirement it is research. Every subsequent time it should be retrieval, and the gap between those two is where a great deal of expert time disappears.

By day 60 you should be able to say how long your current process takes, in numbers, and to point to interpretations that were reused rather than redone.

The final month connects the pilot to the business. Connect regulatory change monitoring to the products and markets it actually affects, so that a change arrives already filtered against your portfolio rather than as an undifferentiated alert. This is what assessing regulatory applicability against a specific product profile is designed to do, and it is usually the point where the volume of work a team is carrying visibly drops.

Pilot a market expansion assessment for one or two target markets. This is deliberately forward-looking rather than remedial. It demonstrates that regulatory intelligence can inform a decision the business has not yet made, which is a different conversation from validating one it already has.

Then begin reporting progress through a simple dashboard shared with product and business leadership. Simple is the operative word. Two or three metrics, updated regularly, shown to people outside compliance. A dashboard nobody outside the function sees is a record rather than a report.

At day 90 you are making a scaling decision, not declaring a project complete. The question is whether the model held: did the workflow survive contact with a real product cycle, did cycle time and time to evidence move, and can product and engineering describe the process the same way compliance does?

If the answer is yes, the second product family is significantly easier than the first, because the workflow, the interpretation library and the reporting all transfer. If the answer is no, ninety days is a cheap thing to have learned that from.

The goal is to prove a better way of operating. Once teams have a repeatable process, clear ownership, and measurable results, scaling becomes significantly easier.

Three patterns account for most failed attempts.

Starting with the technology decision. Choosing a platform before defining the workflow means the workflow ends up shaped by the tool rather than the business. Define what good looks like first, then decide what supports it.

Scoping by function rather than by product. Taking on “all evidence management” or “all regulatory monitoring” across the business sounds like a sensible slice, but it means changing how every team works simultaneously. One product family end to end is harder to justify and much easier to deliver.

Measuring at the end. If the first measurement happens at day 85, there is nothing to compare it to. The baseline is the deliverable of month one.

  • What should be in the first 30 days of a compliance improvement plan?
    Definition rather than change. Define the compliance workflow for one priority product family, establishing launch gates, evidence requirements, and escalation paths for ambiguous regulatory decisions. Identify two or three success metrics and record a baseline before anything changes.
  • Why start with one product family instead of the whole business?
    Because a single product family is small enough to change without renegotiating every existing process, and large enough that the result transfers. The playbook’s position is that the objective is not to solve everything at once, but to establish a repeatable operating model that can then be scaled.
  • How do we decide which process to focus on first?
    Work through the playbook’s organizational alignment questions with product and business leadership, focusing on where compliance issues most often delay delivery or market access, and which manual activities consume the most expert time. The twenty-statement scorecard in the playbook’s appendix reaches the same answer faster: whichever practice scores lowest is generally the one to tackle first.
  • What should we measure during a 90-day compliance pilot?
    Cycle time from regulatory change to actionable decision, and time to evidence when a customer, auditor or regulator requests it. Both should be measured in month one to establish a baseline, then tracked throughout. Two or three metrics is the recommended number.
  • What happens after 90 days?
    You make a scaling decision. If the workflow survived a real product cycle and your metrics moved, the second product family is considerably easier because the workflow, interpretation library and reporting transfer. If it did not, ninety days is an inexpensive way to have found out.

This article is adapted from Adherent’s guide, The Ultimate Product Compliance Playbook (published August 17, 2026). Further developments may have occurred after publication. Download the full playbook for the maturity model, the full 20-statement scorecard, and the complete 90-day roadmap, or speak to Adherent about applying it to your own compliance operations.

See Adherent in Action

Discover how agentic AI is reshaping product compliance for global enterprises.