GDPR and similar legislation represent a significant challenge for companies of all sizes. They tend to be rather complex and easily overwhelming, which quickly leads to frustration and unnecessary costs. Yet, they share a similar solution pattern. In this series, I would like to share with you how such legislation could be handled from a product manager's perspective.
GDPR—probably the most trending acronym in the digital world at the moment. Some welcome it as a long-awaited evolution, for others, it's a nightmare. But General Data Protection Regulation isn't the first legislation of such an impact in recent years. Some of you might remember another one from 2015 that was changing how VAT is charged for digital products sold within the EU borders.
Now, you might be wondering what these, at first look, quite different legislations have in common, apart from the issuing authority and the scary codename (you can bet that VAT2015 was as scary back then as GDPR is now)—but both legislations represent a major change to businesses and the way they operate, a project of a large but unknown scope, represent a major fine if companies aren't compliant with them, and both might impact your product portfolio in a certain way.
In this series, I would like to share my experience from projects that should ensure product compliance with a certain legislation, tell you about the challenges we faced and share our lessons learned. In today's blog post, I want to give you a high-level overview of how such a project can look like and what you should be prepared for.
Are you ready? Let's start!
Understanding the Motivation Behind
I believe that the first and most crucial thing is actually understanding the motivation of the legislation (and no, it's really not because lawyers need more business opportunities). Understanding the motivation of the given legislation will not only help you to overcome the negativity and resistance that usually comes with such complex legislation but also with product and process decisions, as you can impersonate your typical customer and it can help you drive important business decisions.
In the case of the GDPR, it was the strengthening of privacy rights of your customers. Rights that were ignored or abused with the rise of digital transformation. And let's be honest here, you as an individual didn't like it either—just remember how many unwanted emails or phone calls you received just because a database with your personal emails was sold to a third party, and how your every action was tracked and analyzed without your consent or even knowledge.
Another reason why you should understand the motivation is that most likely you're going to be the "go-to person" for questions regarding the legislation. And believe me, people are going to ask. A lot. You'll need to answer the questions on a daily basis, explain the motivation, you'll need to "fight" naysayers (here, motivation is going to be the most useful) and actually drive the development by clearly communicating priorities and scope. You don't have to be a legal expert, but you should have a clear overview of the legislation, which leads me to the second point: gathering information.
Try to get as much information as possible, even though it might seem as an impossible task at the beginning. At first, it's going to be scarce and probably forecasting doomsday, but eventually, it gets clearer. There are going to be webinars organized and other resources released by various third parties with domain expertise or by technological market leaders. For example, there was a series of webinars organized by Microsoft focused on the introduction to the GDPR problematic, there might be meetups in your area, you can find paid training or other various resources online. Unfortunately, these sources will provide you with only general information and once you get to know the basics, the information will start to repeat. You shouldn't expect that you're going to get all the information you need and all the answers for your project from the aforementioned information sources.
Luckily, there's one resource that you should always check out and refer to—the legislation itself. It's always publicly accessible, at least in English (in the case of international legislations), and they're the only one source that can be trusted 100%. However, if you're not a legal expert, you're most likely going to need assistance from one to actually translate the legislation into product requirements. Typically, your company will undergo an audit, which tends to be complex as it will cover many areas, not just the product. Based on my experience from GDPR and VAT2015, the major areas such legislation typically tackles are process related and changes to the organization. Therefore, the initial analysis might not be driven by the product management team, but rather by legal, financial, or internal teams.
However, this doesn't mean that the analysis of the impact on product should be discounted—it is still a very important part of the whole project! But it is important to realize that the analysis of the internal processes and other areas might be given higher priority, and you're going to wait for the audit results longer than you might expect. It can even take several months (it was almost four months in our case), so be sure to start as early as possible.
Nonetheless, the analysis is the most important and largest part of the project. All things considered, you should never underestimate the analysis and audit as it can turn out to be a costly mistake!
MVP or More?
When you have collected the necessary information, there are two ways you need to look at the upcoming legislation from a product manager's perspective.
First, you need to gather all the requirements for your product to be compliant. It might be some minor changes, or it can change your business drastically. These requirements will typically be driven by the audit results and the other information that you collect. And that's why you should start with the analysis early as from my experience, it is easy to underestimate the development scope you might face and you're also often waiting for the auditing company.
Second, you have to think how the new legislation will influence your customer or the end users of your product. Do they have to comply with the same regulation? Are they going to face the same issues as you do? How will the new legislation change the way they use your product?
Both views are very important because they will help you to decide which path you'll choose—are you going to implement the minimum required for your company to be compliant with the new legislation or are you going to go the extra mile and provide support for your customers to help them become compliant as well? Is the new legislation going to be a necessary evil or a business opportunity? In the next article of this series, I'm going to show you how we did this evaluation for our products so you have an idea how you can approach similar projects in the future.
Another important thing to consider when analyzing the scope is your release cycle. In general, the longer your release cycle is, the sooner you'll have to start with the analysis. The reason is simple: if your release cycle takes up 12 months and you're releasing every autumn, you're going to need to address the compliance requirements before the legislation comes into effect. That's the only way your customers can start using the product and become compliant themselves. On the other hand, if you're in the SaaS business and have more flexible releases, you can afford to take a little bit more time, but you shouldn't rest on your laurels either.
Embracing the Waterfall or Not?
"Waterfall is dead. Long live agile." If you're working for a software development company, I'm pretty sure that you've already heard something along these lines in your life. And to be fair, I believe that being agile and lean is the right way to go. Unfortunately, legal projects tend to differ—you're going to face a "fixed time, fixed scope project" as you can't be partially compliant and there's a fixed deadline.
Moreover, as I mentioned before, you'll have to invest heavily into analysis and the audit, gather the requirements, define the scope and then start the implementation. This sounds like a prime example of a waterfall, doesn't it?
But I don't want to discourage you from agile development, after all, we don't live in an ideal world and things tend to get complicated. You might face situations where you don't know the full scope yet (for example, because you're waiting for the audit results and/or you're running out of time), and you need to start with the implementation. In these situations, you'll have to be agile and start lean. From my experience, you can start with things that have the clearest scope and not expect any significant changes. You can then use the time you get while these things are in development to prepare the rest of the scope. However, be prepared that the audit results might raise new requirements impacting the original scope and, therefore, introduce costly changes.
The last thing I want you to realize is that getting information from a development team might take longer as well, especially if the team needs to do some research itself. Let's say that, for example, you want them to check the viability of a technical solution and the team is using Scrum. If they follow the rules strictly, they're going to estimate the research and plan it into the upcoming sprint, which may take up to two weeks (depends heavily on your Sprint length). Add the Sprint duration and we're at 4 weeks of waiting time. I hope this demonstrates why it is important to start early with preparations and research.
I'm not going to lie, compliance with a new legislation, especially an international one, is always a tough nut to crack. And to be fully honest, even for us, it was something new and we faced many of the challenges I describe in this blog post. I can tell you that it's going to be difficult, it's going to suck, but it's still manageable project.
I hope that today's blog post helped you understand a bit on a high-level what you are going to face and where you should be careful. In the next part of the series, I will elaborate more on the audit, I'll show you how we were analyzing what features to deliver to our clients, and why we decided to implement more than just the MVP needed for the compliance. Until then, stay tuned and let us know in the comments what was your experience with GDPR or other legislation.