This article is written by Vanya Verma from O.P. Jindal Global University. This article will discuss what product managers should know about GDPR compliance.
Table of Contents
A product manager entails collaborating with a wide range of stakeholders, including customers, senior management, departments, vendors, the engineering team, and the design team, to name a few. Fundamentally, all of this is done to achieve a single goal: to solve users’ issues, or to satisfy their requirements, or to empower users to achieve their objectives.
Though the goal is to solve users’ problems or, in other words, to meet their wants. After 2011, the EU Commission discovered that tech giants were tampering with EU citizen’s personal information. And this is a violation of an individual’s fundamental rights because the data they possess is their own. As a result, the EU Commission published the GDPR (General Data Protection Regulations) law in January 2016, which has been in effect since May 25, 2018.
GDPR stands for General Data Protection Regulation, and it applies to every company that has customers in Europe. Even if one’s company isn’t based in the EU. GDPR will apply if one delivers products and/or services within the EU as a non-EU entity. GDPR’s purpose is to protect the European Union (EU) citizens personal data and restrict how it can be used. On May 25th, 2018, the GDPR rule came into effect. The EU regulators have made it clear that any explanation for non-compliance after this date would be rejected. Especially in circumstances when sensitive data has been leaked or personal information has been stolen from one’s system. Because of Brexit, the United Kingdom is exempted from GDPR. They expect the UK to have its GDPR version.
GDPR attempts to bring all data protection laws under one umbrella. The ones who do not comply may face fines of up to 4% of their annual global revenue or a fine of up to € 20 million (whichever is higher) per infringement.
When one gathers data linked to an EU person, they have the right to know what data is maintained, why it is kept, and how long it is kept. Users have the right to access (“Right to Access”), export (“Right to Data Portability”), change, and permanently delete all of their data from one’s systems (“Right to Be Forgotten”). They should be able to access their information as readily as they entered it in the first place.
GDPR is not the monster it is made up to be, even though it places a lot of pressure on businesses. People are increasingly using the internet to communicate with friends and family, shop, read, and even manage their finances. This has enabled businesses to give individualised experiences to their customers by allowing applications and websites to capture client behaviour. GDPR enforcement has given EU residents more control over their personal data. This information belongs to one’s customers, according to GDPR. They own it and have the right to select who and how it is consumed. On the other side, it assists firms in becoming more customer-centric and establishing trust.
Product manager and GDPR
Since the product management team is aware of the end goal, a new parameter has been added that users should have data control. It’s been talked about data-driven decisions and hundreds of stories about them, but there are a few questions:
- Where did the data come from?
- Whose behaviour pattern(s) are we keeping an eye on?
- Who are we segmenting/targeting?
- Why are we profiling users and what are we profiling them for?
- When are particular events triggered during the user journey?
The answer to above all is: users personal data
A product manager is responsible for establishing the GDPR mindset in the product in collaboration with their organization’s DPO (Data Protection Officer). There are a few rules that all Product Managers should be aware of, and new features/EPIC should be prioritised depending on them:
- Data minimisation
- User rights to data- Data Subject Access Request (DSAR).
- Data is passed back and forth between departments and sub-processing companies.
- Data Controller- the entity that collects data from users to provide their products and services.
- Data Processor— the entity who process that data given by the Controller
- Consent- is the king while defining any feature or the user journey. Also, this applies to any communication we do with our users across the department i.e. Marketing, Customer Support, Compliance.
Guide for product managers to comply with GDPR
Read and research about GDPR
As product managers, they are the experts on their products. This also qualifies them as the ideal person to translate GDPR into new product features that need to be implemented or mapped to.
When it comes to something as important as GDPR, a product manager should start by reading and researching it. It is beneficial to familiarise oneself with the law. Before diving into the legislation itself, read the summarised versions produced by industry specialists. This will give some context and a rudimentary knowledge of what GDPR was all about, which the product manager could work with before moving on to the more comprehensive version. Product managers must do both: start with a rudimentary version to obtain an overview, then move on to the formal version that is publicly accessible. That would be a reliable source of information.
The product manager will also be the point of contact for a variety of issues, including product, architecture, and the new legislation itself. This in-depth study assists in responding to the never-ending barrage of queries one receives from various sources both inside and outside the company (customers).
Familiarize with the architecture of the product
Use this opportunity to learn about the company’s technology stack if not done before. Learn everything there is to know about the product’s architectural plan, the frameworks in place, and which system components have access to client data.
Here are some of the main questions this exercise would help to answer if one is a product manager:
- Where is the customer’s data stored?
- What is the aim of data storage? Do we need the information we’ve gathered?
- Is any personally identifiable information, such as a social security number, stored in my product?
- What types of third-party apps are available for my product? What are they doing with my customers’ information?
- What are the ramifications of deleting the data from my product?
- Is the product equipped with all of the features we require to assist our clients in responding to data requests?
Think about how GDPR affects the customers
With B2B SaaS, it was critical to recognise early on that not only does one’s product need to be compliant, but they also need to enable their customers to be compliant. This tiny distinction affects how they approach product updates and what they make available to the customers. If they are a B2C company, for example, they can run a script in the background to delete data when a customer asks for it.
However, as a B2B company, it was critical that companies that used our products be able to erase their users’ data from our systems.
Keep an eye on industry experts and competitors
Sign up for newsletters and blog postings to stay informed about what’s going on in the industry. Listen to their speeches and PR releases, and keep a watch out for their updated terms and privacy agreements.
Many industry leaders, such as Microsoft, have hosted GDPR webinars. Attending these events not only helps one understand how they are approaching the legislation but also provides one with a good picture of what the market is expecting. Both are critical, and the best confirmation one can obtain is a combination of the two.
Start early implementation of GDPR
Allow adequate time for last-minute alterations and any unexpected situations that arise during testing or reflection. It is easier to make judgments and get them executed if one has a staff that understands the significance of the law. Alternatively, one can correct their course.
Perform end-to-end test runs before the big day to ensure the process doesn’t break at any point. If one is a B2B organisation, getting started early is especially vital because their customers must be compliant on the date the legislation takes effect. This implies clients will start asking questions much sooner, and they’ll need to allow them enough time to try out what they’ve produced for them.
Work closely with a legal team
Working closely with a legal team is the first step. The legal team in a company must be familiar with the law, the product, and the technology. They will decide how and to what extent to approach the regulation.
One should master their translation abilities. On one hand, one should get familiar with the important legal words and explain them to their coworkers who are unaware of the rules. On the other hand, one has to explain the product and technical aspects to his legal staff so that they can make the difficult decisions.
Research and look for inspiration
Know the domain
When dealing with cross-system product duties, domain expertise is one of their most valuable advantages. One will save a lot of time if one knows where the potential traps are.
Start by documenting everything one can about their system’s user data:
- Does one have any users who might be EU citizens? It’s important to note that the user’s location has nothing to do with their citizenship or rights.
- What is the location of data storage? Is the data kept in the European Union? Look for unfamiliar data storage such as logs, research data sets, backups and replications, and abandoned services.
- What is the aim of data storage? GDPR emphasises data minimization, which means not keeping data one doesn’t need.
- Is there any Personally Identifiable Information (PII) stored in one’s product? Does the product save personal data (e.g., name, address, birth date, Social Security number)?
- What third-party service providers are employed (e.g. photographs, comments, blog posts, transactions)? Do they keep user information in their databases? If third parties do not comply, one’s legal team must decide how to respond.
- What are the consequences of erasing data on a product? Is there anything that needs to be changed in terms of the user experience?
Investigate what other companies are doing, just as a person would for any other product. However, if the person started working early, this may be an issue, as many companies have a similar release deadline.
If there isn’t a live product to look at, consider looking for:
- Support forums, where customers will ask questions about the new rule and how the company will handle it.
- Support articles: These are occasionally made public before the real product is released to reassure customers.
- Some companies provide information about their resolve to comply with legislation through blog postings and public relations announcements.
- Conferences, lectures, and panels are all available.
It’s time to decide how one will present his answer. As is customary, the product comes first, followed by technology and architecture. Some of the questions one should be asking himself include:
- Which components can be manual and which must be automatic?
- How does the support model appear?
- If one is working on a large integration project, one should additionally consider: Whose responsibility is it to ensure that the entire integration process runs smoothly?
Depending on the size of a company, delving into the nuances of each product may be difficult. This is why one should identify domain owners and give them the authority to make their judgments. This can be accomplished by providing them with clear instructions and motivation. Establish security rules in collaboration with security professionals. When handling PII, an organisation should have a policy in place to deal with data breaches as well as general security requirements.
One’s duty now is to guide domain owners on how to execute the regulation. Allow the legal experts to explain how each component of the legislation will be interpreted and how the company will handle it. This will assist owners of various clubs in making their selections.
When communicating with distinct personas, use the appropriate channel, medium, and, most crucially, language and vocabulary. Slack is used by developers, while Hangouts is used by UX, PMs, and support agents, and emails are used by higher management. Lawyers, for example, would prefer not to utilise shared documents because they are afraid of agreeing to content that will later be modified.
To make this endeavour work, all of the above-mentioned personas are required; each of them focuses on a different aspect of the picture and contributes distinct perspectives and expertise. One will have to adjust and master his presentation and communication skills.
One should make themself and their staff available for queries through all lines of communication, no exceptions. There will be more edge instances, and some difficult legal decisions will have to be made. One will need to maintain translating between the legal team and the person on the other end of the line.
Keep a paper trail
Keep a record of all the slides, documents, and decisions one has made. This is good practice for any project, but it’s especially crucial when dealing with regulated items. It will assist in running a project more effectively and afterward in comprehending the decision-making process.
Major elements are as follows:
Who creates and processes data.
PII and Personal Data are the types of data that are stored.
Data is kept in both logical and physical locations (BI, logs, databases).
Who are the third-party service providers?
Work with support agents to create a methodology for processing requests, complaints, and system errors. In this scenario, establishing a clear identification and verification process is crucial, as an ill-defined method could result in personal data being shared with the wrong individual. Allow plenty of time for support agents to practise following this protocol.
Helping the people whose data one store understands what they are doing with it is an important part of becoming GDPR compliant. This could mean they’ll have some support pages detailing the types of data they’re collecting and why they’re collecting it, depending on what their legal team decides. Make sure that any content that is released is thoroughly reviewed by the legal team to ensure that it is not deceptive or could expose one’s firm to legal liability.
According to the GDPR’s Right to Access article, data must be provided within 30 days. Consider the following:
- How will one know if there is a problem? With their development team, discuss monitoring and alerting options.
- How will issues be addressed, and when will they be resolved? An escalation policy for system failures must be discussed ahead of time.
Complying with the GDPR is challenging. It’s not, however, something one can ignore. Because the Act was new at the time, there were numerous obstacles. It may, however, be done correctly if one has the clarity and the proper individuals to assist them. Even if there are many different interpretations of this legislation, one will eventually figure it out. GDPR is paving the way for a more secure online environment; it is the forerunner of good things to come.
The product managers should start putting mechanisms in place immediately to detect data breaches if they haven’t already done so. Make sure to have a regulatory champion (or become one) who creates a checklist for all teams to refer to, including marketing, product, engineering, and support. Conduct frequent audits to ensure there have been no data breaches. Knowledge regarding GDPR will also grow over time. Continue to be aware of what may be overlooked and adapted.
Students of Lawsikho courses regularly produce writing assignments and work on practical exercises as a part of their coursework and develop themselves in real-life practical skills.
LawSikho has created a telegram group for exchanging legal knowledge, referrals, and various opportunities. You can click on this link and join: