GDPR—probably still one the most trending acronyms in the digital world. Some welcomed it as a long-awaited evolution, for others, it was a nightmare. But the General Data Protection Regulation wasn't the first legislation with such an impact in recent years. Some of you might remember another one from 2015 that was changing how VAT was charged for digital products sold within the EU borders.
Now, you might be wondering what these, at first look, quite different legislations had in common, apart from the issuing authority and the scary codename (you can bet that VAT2015 was as scary back then as GDPR was more recently)—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 still going to be the "go-to person" for questions regarding the legislation. And believe me, people are still asking. A lot. You need to answer the questions, explain the motivation, "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.
It was necessary for you to try to get as much information as possible to be ready, even though it might have seemed an impossible task at the beginning. At first, it was probably scarce and a forecasting doomsday, but eventually, it hopefully got clearer. There were plenty of webinars organized and other resources released by various third parties with domain expertise or by technological market leaders. Unfortunately, these sources provided you with only general information and once you got to know the basics, the information started to repeat.
Luckily, there was one resource that you should have always checked out and referred to—the legislation itself. It's publicly accessible, at least in English (in the case of international legislation), and they're the only one source that could be trusted 100%. However, if you're not a legal expert, you're most likely needed assistance from one to actually translate the legislation into product requirements. Typically, your company underwent an audit, which tended to be complex as it covered many areas, not just the product. Based on my experience from GDPR and VAT2015, the major areas such legislation typically tackled were process related and changes to the organization. Therefore, the initial analysis might not have been driven by the product management team, but rather by legal, financial, or internal teams.
However, this didn't mean that the analysis of the impact on product should have been discounted—it was still a very important part of the whole project! But it was and 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 existing 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 legislation influences your customer or the end users of your product. Do they have to comply with the same regulation? Are they facing the same issues you do? How has the legislation changed 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 earlier you have to monitor your compliance. 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 those compliance requirements sooner. That's the only way your customers can start using the product and stay compliant themselves. On the other hand, if you're in the SaaS business and have more flexible releases, you can tackle any compliance issues more regularly.
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" and GDPR is already upon us.
Moreover, as I mentioned before, you would have had to have invested heavily into analysis and the audit, gathering the requirements, defining the scope and then performing 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 still face situations where you don't know the full scope yet (for example, because you're waiting for compliance results, etc.), and you needed 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 compliance 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 and testing 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 four weeks of waiting time. I hope this demonstrates why it is important to start early with preparations, research, and implementation.
I'm not going to lie, compliance with any 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 and still face many of the challenges I described in this blog post. I can tell you that it's difficult, it sucks, but it's still manageable.
I hope that today's blog post helped you understand a bit on a high-level what you are facing 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 compliance. Until then, stay tuned and let us know in the comments what are your experience with GDPR or other legislation.