When Regulations salute Product Managers with “Hello Earthling!” I wanted to write a blog about my alternating view on how I welcome regulation in product management. It’s unsurprising to see Product Managers from diverse levels who typically avoid learning and commenting about regulation. I was always against putting lawyers to the front and receiving to-dos from them directly. Indeed, we should listen to the lawyers and find a common way to make things work.

⚠️ So far, I’m directly involved in regulations about data privacy / GDRP, accessibility, medical devices (as software and hardware), and information security, and I’m indirectly involved in some financial regulations. Please review this blog post under this disclaimer; none of my views will substitute the position of lawyers and will protect you (directly).

As a generic work loop, PMs will get insights, build a concept, and validate and scale it. The same applies to the regulatory topics. I will cover my observations by following this analogy.
Insight Build Validate Scale
⬇ ⬇ ⬇ ⬇
Regulatory Insight Develop a MVP of Regulatory Compliance Validation with Lawyers or Notified Bodies Implement in Scale;Establishing a system of continuous compliance

Illustration of 4 processess

1. Insight

Whenever a PM doesn’t believe in the cliche of “We lack this feature, we should add this feature immediately,” they will try to do user research to assess the situation and rationalize the motive. Belief and bet-based work sometimes occur, but this shouldn’t be business as usual. Accordingly, a regulatory insight gathering won’t work by directly listening to the lawyers. Lawyers might offer actions more than required to be on the safe side. PMs should approach the lawyers by approaching a customer’s feedback to uncover the insight.

The main thing to learn is the main thing of the regulation. For example, GDPR is based on which data is personal and how it’ll be managed; Medical Device regulations are based on assessing the risk of the product and how to mitigate risks, etc. Each PM should have clarity in describing the purpose in one sentence. This is the most extensive guide when a regulation offers conflicting action.

What is the minimum requirement, what is the favorable requirement, and what are the optional or advised requirements (best practices): these are the primary questions to answer. In other words, asking, “Is this mandatory?” is a life-saver. Especially while regulations use words like shall, should, might, must, etc., these meanings might differ from the daily usage, and “required” vs. “would be better”s can be mixed easily.

I saw many advisors who got their position on knowing the regulation for specific product types and forgot the rationales behind and used 3rd party guides as must-have standards. Even when I asked why this 3rd party guideline/checklist is mandatory, they couldn’t answer. Sometimes, they were right to offer these things because it was easier to apply, but sometimes, they added unnecessary workload.

If you don’t know how to validate/trust the people you work with, you might lose time because nobody can understand whether a better version exists if they don’t observe or doubt a better one. Valid for regulatory advisors.

At this point, I want to add some tactics for validating advisors, just by relying on and using fundamental PM skills and practices (not any skills and resources else);

  1. Doing a brief research before talking to the advisor
    1. DO’s
      1. prepare a list of upfront questions before reading anything
      2. block a time for this research
      3. skip the details, have the primary understanding
      4. visual checks: Google image search will make you resourceful to have quick ideas; there should be lots of process diagrams and infographics about your regulation
    2. DO NOTs
      1. be discouraged when you don’t understand some terms
      2. invest too much time while looking up regulatory sources with details
  2. Cross-check the advisor
    1. If possible, ask multiple advisors
    2. Check the information you get with online resources
    3. Search for a more lean format than your lawyer/consultant gave you. You can compare guidelines, checklists, action lists, forms, or SOP (standardized business processes like BAU; business as usuals) examples
    4. You can try to google “how to implement X regulation agile.”
    5. Cross-check the regulations or advisors from different markets/verticals/countries.
  3. Getting a quotation is a way of learning
    1. When I try to get the best quote, I ask questions like these;
      1. “I know that X is suggested but not required. Can you confirm?”
      2. “you offered to include Y, but the regulation does not mandate this; why did you include it? we don’t need this.”
      3. “You didn’t include Z; this is not mandatory (or: don’t you think this is not mandatory), but we think we might need this. What is your suggestion? If this will be required later, what would be required later?”
    2. The last 2 questions oppose each other. I observed the sunk cost of a lousy advisor who didn’t openly share the process details to make the sale by showing an easy process. Sometimes, someone can offer a more straightforward way through their experience and examples; it is important to distinguish whether this contact is hiding something or making things simpler. Both methods are uncluttered; just one returns with a pop-up cost. So, the importance of having opposing questions comes from this lived experience.
  4. Invest in Product Sense, Look for Tools, and Understand their Competitors
    1. One way to understand the advisor is to look for free, open, or proprietary tools or checklists to understand the regulation landscape.
    2. Some tools can show a need for a systematic approach on a larger scale or demonstrate the required resources to comply with the regulation by displaying a VS table of the necessary work with their tool.
    3. The best resources I saw so far were some product blog pages. Especially if that tool targets small-scale businesses, they generally offer the main benefit of starting easier and showing the barriers/difficulties of that regulation. Other tools usually don’t try to mention the logic/rationale of the regulation requirement because scaled businesses are doing the operation with or without reason; the important thing is to convince them to save time/energy.

2. Build

While building something for regulatory compliance, we can split this effort into 3 parts;

  1. Initial Investments
  2. Routines (Agilization of the Regulatory Work)
  3. Preparations for Pop-up Requests

Regulations differ in how much effort they need from these 3 steps. Some regulations don’t have pop-up requests; they announce the changes 2-4 years before. Some regulations rely on routines so much they don’t need so much initial investments.

2.1. Initial Investments

I shared some research and insight-gathering tactics above to gain an understanding. Additionally, it would be great to have a perspective on how much effort you’ll need with your team in this phase. As a generic rule, understanding the regulation and planning required actions takes ~10-15% of the total effort of the compliance.

It’s not rare to see teams stuck in the middle of the compliance process and cancel or postpone the compliance program, even if they don’t lack resources. (As a probable cause) I noticed these teams had some prioritization problems or analytical approaches. Especially if the regulation requires some pop-up changes, the teams can break something in the production environment.

In this stage, I recommend having a deeper understanding of prioritization and focusing on the default PRD (Product Requirements Document) definitions. For example, they’ll only be able to work if the teams have a shared sense of the acceptance criteria and phasing out the scope when a popup change is required.

In summary, do;

  • resource planning
  • Deep dive into your PRD / user story definitions
  • reach a common understanding of the criteria
  • practice about prioritization cases
  • review your backlogs / retro notes from the periods of prioritization problems

2.2. Routines

Every day, more regulations are shifting to periodic checks, which are more important than the initial efforts. The biggest misconception is to rely on the certifications/approvals from the initial process.

Medical regulations, for example, require a periodic check on reviewing your risk assessment. Your product has been living and changing since it was in use. So, you might learn new risks from user feedback or complaints. This is the point of regulation asking you: do you encounter your product’s unknown risks or usability challenges? It’s so much related to what agile processes recommend, too. For example, in scrum methodology, a retro note is prepared at the end of each sprint. By adding a few routines to the existing ones, regulatory compliance work can be cascaded into usual operations.

💫 Tip: If you’re duplicating retro logs from a Confluence template, you can include some fields related to regulatory compliance in the template. If required, you can add a routine when completing a sprint group. This way, you can split a massive work into small/atomic habits and use the cumulative effect.

Another thing is to improve the PRD template. Every company builds its templates from lessons learned and what they need in that business domain. So, like GDPR started to take part in our PRDs as a universal practice, we can utilize this example to make our products accessibility-compliant or medically compliant.

In the beginning, first investments might require a deep focus. Still, after doing that, compliance maintenance can be done as a part of acceptance criteria or practices in user stories. Sometimes, regulations mandate a “management responsibility” to place enough resources for compliance. The main reason for this mandate is to see a living culture inside the companies.

A routine illustration; PRD and User Stories followed by Sprints. Sprints gives outcomes of retro notes and testable product. Retrospective notes can be uses as a source of risk assessment when prepared for it. A routine illustration; PRD and User Stories followed by Sprints. Sprints gives outcomes of retro notes and testable product. Retrospective notes can be uses as a source of risk assessment when prepared for it.

2.3. Popup Requests

National regulators are famous for their pop-up requests, especially in finance. Because of the high exchange speed of financial assets, preventions require rapid response, which is an understandable reason. So complaining about pop-up regulatory requests might be boring and energy-consuming for a PM. Most of the time, I gave examples of a product that crashed in production chronically.

If you have a problem in production, you first try to address issues with paying technical debt. Still, you might face difficulties in the show; in this case, you can put watchman developers to monitor production. Valid for regulation.

Another pop-up request might originate from a competitor or provider breaking change.

As examples may continue, the important thing is to notice that market conditions require popup changes and efforts. Regulations are just a subset of market conditions. Instead of complaining about regulations, a product structure can change its perspective to planning for workloads. You should put an overseer of regulation from developers and PMs. Or, if you don’t have many resources on a small scale, you can invest more in competitive intelligence.

Competitive intelligence is not just about analyzing the competitors but also having intelligence of the landscape you’re playing, including regulations. The best thing is that there are lots of resources and bulletins about each regulation, so having an insight into what might come is easy to obtain.

3. Validate

The best source of validation is the lawyers and regulatory consultants. While they review your work, they might complain about your different formats.

When a PM requests validation from another person, they might feel like a developer who gets feedback from code review. 😀

So, to avoid being affected by human error and misconceptions, two ways of communication are required to get approval/review. Most PMs can skip this part and apply the feedback as-is without putting that review into context.

REVIEWS 10 LINES OF CODE: FINDS 10 ISSUES. REVIEWS 500 LINES OF CODE: LOOKS GOOD TO ME

4. Scale

To sum up the scaling needs;

  1. Did you implement requirements;
    1. into your agile routines?
    2. Into your acceptance criteria?
  2. Do you do periodic checks on compliance?
  3. Do you train your team on compliance needs?
  4. Do you assign regulatory compliance efforts to team members? Or do you assign it to a few people?
  5. Do you check compliance needs between BAU (Business as Usual) targets?
  6. Do you run competitive intelligence studies (both for generic and regulatory needs)?

If you implement a yes-full system, I can confidently say that you’re prepared for 95% of regulatory compliance needs for a living product in production.