Encryption is not Binary
Blog: Tyner Blain
If you ask someone if they require encryption on their device, first of all, you will likely get one of two answers – yes or no – useful for segmenting your market or developing persona. If you’re lucky, you’ll get a better answer – “you’re asking the wrong question!”
Be Outside-In, Not Inside-Out
Inside-out thinking is taking your current view of your product (or product-to-be), and mapping it to the problems you discover in the market. By contrast, outside-in is to understand problems your prospective customers face, and build viable solutions to those problems.
People don’t require encryption, they require protection of information. You could achieve that protection through encryption, or by embedding your device in epoxy, or keeping it in your pocket at all times.
As an example, in 2008 the iPhone 3G’s user storage was not encrypted. Data Protection was provided by unlocking the user interface to the phone with a PIN code. The expectation was that you had to use the interface to access the stored data, so by protecting the user interface, the data is protected. Without encryption.
Inside-out thinking is being an order taker, providing what is requested, not what is needed.
Outside-in thinking is recognizing that people want to protect their data from others.
Outside-in thinking might even re-frame the problem as one aspect of a need for privacy. It just depends on what context in which you are defining the scope of the problem you wish to solve.
Applying Kano to Data Protection
Kano analysis is one of the key components of what I teach in DIT’s product management program every spring, and will also feature in one of the sessions of Product Owner Survival Camp in May 2016.
At first glance, what seems obvious in 2016 is that data protection – from the point of view of the user – can be classified in one of three ways
- I must have data protection on my device
- I must not have data protection on my device
- I am indifferent about data protection being available on my device
While the Kano model supports the notion of requiring that a feature not be present I have not found it useful yet in a product management context. Partly, I suspect, because with an outside-in perspective, you aren’t looking at the presence or absence of features, you are only looking at capabilities – and I haven’t found a product where the concept of “I would have bought it, except someone could use it to do this other thing I don’t like, so I will not buy it.”
It is possible, in some markets, that the ability to protect data would be a delighter. In those markets, the capability would be disruptive.
Data Protection, however, is not a boolean capability. There are degrees of protection. This implies that there is a notion of good enough protection of data. What might that look like?
Good Enough Data Protection
Building on a rapid refresher of first principles of applying Kano modeling as a product manager, we start with a realistic view of the more is better characterization of problems.
[The notion of good enough is added to the model. There is some level of security that a user perceives about their data (using slightly more outside-in language), as a function of how well it is protected (outside-in), utilizing whatever technology (inside-out) the product happens to use.
Below this threshold, a user will be unsatisfied, and above the threshold, the user will be satisfied. When we’re defining an MVP, we need to make sure we satisfice the user.
We want to aim for viable, not just minimal with our product.
A common source of product failure is delivering incomplete solutions to problems.
Adding some illustrative data points to the model, we get the following:
[The degree to which you need to solve a particular problem is defined by your users. It may not simply be a Boolean decision (“is data protection a capability?”), it may be a scale of increasing capability (“how much data protection is provided?”).
In the security space in particular, there is the added complexity of deciding if you need to provide legitimate security, or the perception of security, or both. Then you have to decide what that means in the context of your market, customers, competition, and product.
Conclusion
While the debate surrounding the current encryption & phone-unlocking controversy can be interesting, the lesson for product managers is that there is value in understanding how your users frame the problems you hope to help them solve.
Approaching your product from the outside-in – from the perspective of understanding what your users value, is critical.
Framing, or characterizing, the problem the same way your users does will help you determine when good enough is actually good enough.
The post Encryption is not Binary first appeared on Tyner Blain.
Leave a Comment
You must be logged in to post a comment.
