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.
[tweetherder]We want to aim for viable, not just minimal with our product.[/tweetherder]
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.
Scott,
Great article, and very useful. One thing that has been a pain point for me is how to get the other actors in the organization to get to the “outside in” way of thinking (sales in particular). They have long hung their hats on the features train, and this gives some good arguments on how to reset their thinking.
(Also, I just burned more than an hour following your links… Great stuff abounds)
Thanks!
Also – I’m impressed you were able to go through the back catalog in an hour. Maybe you skimmed a couple?
Scott, when teaching/explaining the Kano model, what are the examples you use to illustrate the “Reverse” classification?
My quick & flip example is “ash-tray on a motorbike”.
What are yours?
Thanks, Eric!
I pay very little attention to reverse classifications, generally. Just don’t see them come up to often.
Where they do make sense, however, is when you have different user groups with “competing agendas.”
A laptop for use by a road-warrior business traveler would ideally be lightweight and smaller than the pocket in a typical backpack.
A laptop for use by an avid computer gamer would ideally have an immersive display (e.g. large in size), and weight is not important.
The size of the screen could be a more-is-better Kano characteristic for the gamer (with diminishing returns), where it would be the reverse for the business traveler.
Another example I sometimes use also fits the “competing agendas” paradigm, being what kind of seats you have in your car. If you’re a soccer parent transporting multiple muddy kids and a dog or two and their various sticky snacks … you’d wouldn’t choose the luxury Italian leather seating that others might for their vehicle.
Back to one of the points of your article – when doing a Kano research study it is quite helpful to describe the features in a way that does allow for more-is-better (and not a simple binary). (I’m adding this bookmark to my “How to prep a Kano Survey” tutorial).
Thanks, Eric. I agree, knowing the nature of the problems being solved (or researched) is important to properly characterize what you might do, and how you might do it progressively (incremental delivery), and to form a point of view of how best to compete for prospective customers.