Building Product in a Post-GDPR World [Mind the Product]

It’s GDPR week!

Keep Calm and Manage Data Responsibly!

I’m not going to go into an exhaustive breakdown of exactly what GDPR is, as there are plenty of other perfectly good posts about that. I’m also going to avoid – wherever possible – the legalese and specific jargon that comes with it. By this point, you’re either familiar with it or you’re in for a nasty shock in the near future!

If you do need a primer, or are wondering what practical steps you should be taking as a product manager, then I can recommend several excellent primers and starting points for you.

Given that I’ve been wrapping my head around this with my colleague Amy Roberts for the last few months, what I’d like to do is to unpack what I think the implications of GDPR will be on how we build products, and the kind of products that get built. This is not a dive into the technical aspects of encryption, data sovereignty, or cookie tracking. It is a jumping-off point for a discussion about how our craft will evolve and adapt, starting from May 25th 2018, structured as a couple of key points I’ve been pondering as we approach OMGDPR day.

Penalties and Fines

The first thing most people think about are the fines, and they get scared that the penalties in GDPR are going to put people out of business en masse. Let’s get this bogeyman out of the way from the start.

Yes, the advertised fines are 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 going to change, rather than just what we’re all scared about…

Data Security and Infrastructure Design

Good news! It’s just become a lot more sensible to invest in your database design and clearing certain kinds of tech debt! 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 be treating 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

Given that so many users (and perhaps politicians too) haven’t truly realised the value of personal data, there have been several companies who have very literally farmed their users and harvested their personal data, and gone on to profit from this directly. The reciprocal benefit to the users in a large number of these cases has been negligible to zero – they’ve just been tricked, manipulated, or otherwise encouraged into giving up something that is of value for little to no benefit to themselves.

In some cases, those companies are literally shutting their own doors at the end of the week. In other cases, loud sounds of restructuring and legal buttressing can be heard from behind closed doors.

The Rise of Intentful Product Design

A key practice that GDPR will now require is a clear disclosure of why we’re asking our users for their personal data, and exactly how we plan to use it. No more hoarding of data “just in case”, and no more vague wording that allows grey-hat product designers to ask for data for purpose, and then quietly use it for something else. A few things are likely to change:

1. We will have to get better at designing products that we believe use data to the definable benefit of our users.
2. We will get better at working out what data we actually need to solve a given user problem.
3. We’re going 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.

Users’ product options are increasing, social media is extending everyone’s reach, and the new data protection laws have real teeth, so we’re all going to have to be comfortable standing up in front of all 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.”

Europe vs Global Addressable Markets

I’ve seen a lot of product people and companies try to weasel their way out of GDPR compliance by working out exactly who it applies to. Some extreme cases have just decided not  to supply their service to users residing in the EU. If you’re happy either to sacrifice such a big potential market, or to do the necessarily legal and technical juggling that allows you to treat users’ personal data significantly differently based on their location, then I say go for it.

But it’s worth bearing in mind that laws governing privacy and data usage – and a general desire to loosen individual corporations’ monopoly on user data for financial gain – will gradually spread. Don’t expect to wait too long before the US and various parts of the Asia-Pacific region have similar sets of regulation. I’d suggest that, if you take the route of avoiding GDPR compliance, you are (at best) just buying yourself time.

It’s also worth considering that if a business model relies so heavily on being cavalier with users’ data, then maybe that product (and possibly even that company) has a different problem.

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 might be an interesting (and increasingly relevant) 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 will 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, GPPR is a (slightly messy and designed by committee) 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, not just the ones from Europe.

The post Building Product in a Post-GDPR World appeared first on Mind the Product.

Source: Mind the Product http://www.mindtheproduct.com/2018/05/building-product-post-gdpr-world/