Keep Calm and Manage Data Responsibly because, in this blog post, I’ll try to unpack what I consider to be the implications of GDPR on how we build products.
Don’t panic – I’m not going to go into an exhaustive breakdown of exactly what GDPR is, there are plenty of perfectly good posts about that. I’m also going to avoid – wherever possible – the legalese and specific jargon that comes with it. However, for some practical steps that you should take as a product manager, I can recommend several excellent primers and starting points for you.
Penalties and Fines
The first thing most people think about are the fines, and they worry about the penalties in GDPR. Let’s get this bogeyman out of the way from the start.
Yes, fines can be breathtakingly high. But no, they are not designed to be applied in a company-ending way (unless you really screw up). They’re designed to make you – and more importantly your C-suite – take GDPR seriously, instead of the traditional approach of “we can pay the fines – do it anyway”.
Don’t get me wrong, you definitely don’t want to be at the receiving end of one of these fines, but they’re not an attempt on the part of the EU or the ICO to decimate companies like some kind of economic apocalypse.
Anyway, let’s move on to what’s actually more likely to affect you, your team and your product.
Data Security and Infrastructure Design
GDPR is partially a response to the reality that our personal data has explicit, quantifiable value, and that losing control of it can have massive long-term, knock-on effects on individuals.
It’s effectively a kind of currency, and we should treat it with the same care and respect that we grant to financial data itself. You should treat your customers’ personal data in the same way you’d expect your bank to treat your savings – with iron-clad data security and clear processes for how to handle it in an acceptable manner.
No More Farming Users for Profit
When GDPR exploded onto the scene, so many users (and perhaps politicians too) hadn’t truly realised the value of personal data, and there were several companies who very literally farmed their users, harvested their personal data, and went on to profit from this directly. The reciprocal benefit to the users in a large number of these cases was negligible to zero – they were just tricked, manipulated, or otherwise encouraged into giving up something that was of value for little to no benefit to themselves.
In some of those cases, the companies concerned literally shut their own doors. In other cases, loud sounds of restructuring and legal buttressing were heard from behind closed doors.
Intentful Product Design
A key practice that GDPR requires is a clear disclosure of why we’re asking our users for their personal data, and exactly how we plan to use it. This put an end to hoarding of data “just in case”, and to vague wording that allowed grey-hat product designers to ask for data for a purpose, and then quietly use it for something else. This means:
- We’ve had to get better at designing products that we believe use data to the definable benefit of our users.
- We’ve had to get better at working out what data we actually need to solve a given user problem.
- We have to find effective and elegant ways to inform our users of what we’d like to use their valuable data for, giving them a clearer insight into how their personal details will be used.
The result? The new data protection laws have real teeth, which means we have to be comfortable standing up in front of our users (and, if it all goes wrong, the ICO), and saying: “We want to use your data for this purpose, and we believe it will benefit you at least as much as it will benefit us.”
A new Wrinkle in Product/Market fit?
Product/market fit traditionally looks like a significant and steady growth and retention of paying users. That’s not going to change. But what can be an interesting tool for product people is a kind of “data request fit”.
Assuming your new feature needs data to run (and in this day and age, it probably will), the chances are that you’ll need to jump through a few hoops to inform people of what your new feature will do, and what data you’ll need to power it. Now, you may not have to ask consent, but your users absolutely have the right to object to you using their data in this new and fabulous/abhorrent way.
Your newly data-savvy-ish users might turn out to be an invaluable source of insight into whether your new features and products create as much value for them as you’re getting paid for (and whether it’s going to turn the heads of as-yet-unconverted potential customers).
Respect Your Users
Fundamentally, GDPR is an effort to enforce the mindset and practice of respecting your users as human beings – as people who deserve to understand what you’re doing on their behalf, who deserve to see some direct benefit from sharing their data if it’s being used to generate financial profit, and who will be very literally at personal or financial risk if their personal data is lost, exposed, or otherwise misused.
And as a point of principle, that sounds like a good way to treat all your users.