This is part of a series:
- Behavioural View of Product Development - Part 1
- (this post) Behavioural View of Product Development - Part 2
- Behavioural View of Product Development - Part 3
The Problem Canvas: Customer Section
The Customer section tries to put the customer into full perspective. A customer is someone who has a problem, some awareness of the problem and a common set of behavioural traits. Additionally, despite knowing about the solution you are creating, there is going to be some friction for this customer to adopt your solution. You need to know what this friction is likely to be.
1) Define the Customer
To define the customer, think of a specific persona, or a few personae. You will soon be surprised how wrong we ALWAYS are about this one. It's important to put a qualifier in the persona definition.
I would NOT say that the Dropbox early adopter is a young person who works in tech.
Rather, I would say that the Dropbox early adopter is a [person working in tech] with [more than 5 files to share in a week].
The first square bracket contains the demographic — [person working in tech] and the second one contains a qualifier [shares more than 5 files a week to non-team members]. The qualifier helps us think through more deeply about the target audience.
2) Activation Energy to Take an Action
Here’s a situation. You have created a product, that truly solves a problem for the user base. You know that at least a few 100 of your target users know that your solution exists. But they don’t use your product.
The reason is a bit nuanced and not so simple. Think of the process of adopting a new product as a phase change. We will borrow from Thermodynamics for a moment and say this
For any phase change to take place, the subject needs to overcome an activation energy.
Activation energy is the sum total of all the reasons users may have to stick to the current solution. Once you overcome all the reasons, you will get the users to take the intended action using your product.
As Makers, we need to check all the reasons that can cause the early adopter to ignore our solution. Usually one (or many) of the following:
- Existing Habits: The Early Adopter might be too used to the old way. They may have filled the old solution with data that makes it easy for them to make it work. Existing habits are biggest blockers because Early Adopters, by definition, are people who have found workarounds. This is a “Psychological Cost” and can be beaten only by “Psychological Reward”.
- Other influencers: The Action you are improving is collaborative, and their collaborators might want to continue the old way.
- Migration Costs: The cost of migrating from their existing behaviour is “expensive” to the user. The cost could be in the form of Time (they will have to learn something new) or Money (they will have to re-invest)
- Social deviance (outside the norm): What you are offering is not a common way to do things at all. The act of using your product makes them seem outside of the norm. This can actually be used to your advantage.
3) Problem Awareness
Awareness of the problem is important because this helps you define the part of their psyche that you need to appeal to. Greater the awareness, more the “logical” approach to picking a solution. Lesser the awareness, more the “emotional” approach to picking a solution. For latent needs, users adopt something new only when multiple factors favour the solution — easy to use, entertaining, social effects etc.
Try to identify the degree of their awareness of the existence of the problem.
Do they think they have:
1. No problem
2. Problem, but manageable
3. Problem, some help appreciated
4. Major problem, help seeked
5. They’re dying, workaround built
Once you identify the user base that checks out options 4 or 5 above, you can start to validate whether you are right about them being early adopters. The Lean Approach recommends you build a solution only for the user base that check out point 5. However, finding a common pattern of user types who have “built” a workaround, and reaching them repeatedly is usually impractical.
To get this straightened out, you need to be clear what you define as a workaround. Does it need to be a tool? Does a process suffice? Does a process that is invoked irregularly also suffice?
The more latent the problem is, the harder it becomes to define a workaround. The more clear a problem is, the more likely you are to create a product in a category that will soon be commoditised, and would no longer be a startup game. It is a rare case when you identify a problem that is clear, people have been finding their own ways of solving it, and yet it has been in the blind spot of most entrepreneurs capable of building it. If you chance upon something like this, you really really need to validate if people’s “own” ways of doing it are actually good enough and the problem does not really exist. This is a comparison with the current solutions and quantifying their “suckiness”. This will be covered in the next section.
Get into the depth of the Behavioural View of Product Development in parts 2 and 3 here.
Previous post: Behavioural View of Product Development - Part 1