In my previous article, I was explaining how we chose the scope for our products when were addressing the GDPR's requirements. In this final article of this PM POV series, I want to look back at the whole project of GDPR compliance, share with you where we screwed up, what we learned, and what I expect the future to hold for us.
It's been more than a month since the GDPR came into effect and fundamentally changed the digital landscape. Everyone who worked on the GDPR compliance project is probably going to agree with me that the project wasn't particularly a piece of cake. One of the reasons why "I am working on GDPR" has become a synonym for "I wish I'd made a different career choice back then" for many people was that the compliance project brought a huge scope with a lot of requirements and even more unknowns to be addressed. Unknowns that usually lead to troubles and obstacles during the project. We at Kentico were no different—a lot of the content in this series was actually based on the mistakes we made during the whole compliance project. And even though we managed to deliver the scope we wanted almost on time, we had to learn a few things the hard way since there was no GDPR manual. So where exactly did things go south?
3 Lessons Learned
Similar Products, Different Scopes
First of all, I think our biggest mistake was predicting the project scope for our cloud product based on our experience with the on-premise solution. We first started working on our on-premise product, which had a fixed release date, using it as a pilot to pioneer the path for the cloud solution that had much more flexible release cycles (every two weeks). We expected that as the cloud solution leverages fewer entities working with personal data and based on the previous experience, we created a rough estimate for the work needed. Later on, as we dived deeper, we uncovered other requirements resulting from the different roles (as I was describing in my last article), and also one important requirement from our clients—a local data-center in Europe. This resulted in the scope bloating to a size we hadn't predicted and put significant pressure on our product development's organization. Of course, we could have decided not to implement this requirement, but without this feature, we couldn't help some our European clients to comply with the new regulation and might have risked losing them. Yes, it was risky, but in the end, I think the benefits outweighed the drawbacks and helped us to provide unique value for the end customers. Therefore, my first takeaway from this project is: always evaluate the scope for your products separately.
Patience Is a Virtue You Need to Have
Another thing that didn't go as smoothly as expected was the whole company audit that our products were a part of. It's clear our expectations were a lot different to the reality. We expected that we would quickly get clearly defined actionable action items that had to be addressed. Little did we know that conversations would be super lengthy, the outputs were sometimes so vaguely provided that they needed several iterations of clarification in order to be finalized and actionable. Don't get me wrong, I am not saying the audit wasn't useful or necessary—it definitely helped us to formalize the data processing agenda and define new processes and best practices to guide the data processing. We just expected it would definitely be a smoother and faster process. Therefore, my second takeaway from this project is: start early and don't expect you will have all the information right away, especially if there's an audit or consultation with the third party involved. And also, clarify the expectations—ask them for a sample of the output in advance.
Product versus Process
My last screw-up is tightly related to the previous one: it's not all about the product. GDPR has brought a lot of changes and requirements, but a lot of them are actually rather concerning processes than products. That's why product areas were postponed during the audit, while other departments that process way more personal data, such as HR or Sales, got priority. This means that as a product manager, you have to switch your mindset from product-first to company-first and accept the delays. Moreover, not every requirement will have to be addressed directly in your product. Does the new legislation bring a new process that has to be adopted? Is the expected frequency of this process low? Well, then it might be better to handle the process manually than implement costly support in the product. Therefore, my last takeaway is that it is important to focus on the product, but also try to understand the priorities across the whole project.
Is It Over Yet?
Now, before you pop the champagne, pack and archive all the materials related to the GDPR compliance project, be aware—it's not over yet. In fact, I believe we're at the very beginning. And no, I haven't lost my mind. I know this might sound odd, after all, you invested quite heavily to be compliant with the new legislation, but there's still a lot to take care of in the future. What exactly?
Firstly and most importantly, you will need to embody the privacy by design into your development processes. Gone are the times when you were collecting various data just "because it might be handy in the future". You will have to more precisely define what data you need and why in a formalized way, and you will need to communicate its collection to your customers. Furthermore, you will now always need to assess whether the cool new functionality that you're building is not breaking any of the principles GDPR established—either by exposing some data or by putting you into a new role and, therefore, resulting in more responsibilities. Moreover, you will need to teach data privacy and security principles to every new employee who will work on your product, and you will have to be strict with those rules. You don't want your developers to be creating copies of production databases because they need some data for testing. After all, you don't want to waste all the valuable resources you spent on becoming compliant in the first place, right?
Secondly, you just updated your corporate processes (hopefully including the product development one) and those will need some adjustments along the way as new personal data processing agenda will be incorporated. Also, I'm pretty sure the legislation itself is going to change over time. We will see new amendments and changes to the requirements for personal data processing, and you will have to adapt to these new obligations.
Finally, GDPR might be just the first of much legislation to come. It's not at all unlikely that we will see some changes to the US Privacy Shield or similar legislation arising from the Pacific area, especially after the breakout of data privacy scandals such as Cambridge Analytica. Therefore, if you were relying on the fact that GDPR is affecting only companies that provide their services to European customers (and even if you took it to the extreme, and decided not to do that as well), you might soon face the same challenge anyways.
So all things considered, it's not over yet. But I'm pretty sure, you know what to do now, and it's not going to be as big a challenge as it was six months ago.
One Digital Step at a Time
I'm not gonna lie if I say that the GDPR compliance was a very challenging project. To be completely honest with you, I admit that I caught myself swearing several times over the past few months and I guess you did too. But this whole craziness had a very good motivation and set a solid foundation for a digital future where customers do not have to worry how their data is processed. After all, how do you want your personal data to be treated?
Let me know in the comments what your experience with the whole GDPR project was. What did you learn?