First we should think of the characters that appear around the problem where we are "designing our RPG adventure" and where our product/solution must fit in. For our problem exploration to be complete and balanced we should extend the concept of "customer" considering different characters or roles that people may play when they are in contact with the problem we are analyzing and with the kind of solution we are proposing. Based on Steve Blank's theses we can identify the following preliminary list of characters:
We should always adapt this schema of characters to our problem in particular, because in our case the same profile could play more than one of the roles mentioned above, or some new roles specific to our problem or solution may appear.
Once we have selected the roles that will take part in our "RPG adventure", we'll have to fill in their character sheet (i.e. set up the features of that customer segment regarding the problem we are analyzing), which contains:
The key difference (to make use of this analogy to the right extent) is that, when we are putting Customer Development into practice, we should understand that what we are characterizing are just hypotheses, and we must not take them as true facts on which to build our solution unless we validate them by face-to-face interviews with real examples of those customer segments.
[Haz clic aquí para la versión en español de esta entrada]
- The end-user. The person who is going to use our solution, be in front of it and directly interact with it. We may have to consider different profiles in this character, as our solution's features may be grouped for different end-user roles.
- The recommender. This character has the ability to express an opinion (with a solid fundament or not, being an end-user or just "guessing") about our solution and, therefore, a potential speaker for its virtues and defects. A key character when we are looking for viral growth.
- The decision-maker. The person deciding whether to adopt a solution or not may not be the one that will use it in the end. Depending on the scenario we should clearly bear this difference in mind and avoid any doubts about who's the real customer of certain actions.
- The payer. A key aspect -and not always part of the same role- is who will really pay (i.e. spend part of their "budget") to buy the solution. This character is present in corporate environments as well as family ones.
- The influencer. Those who finally decide whether to adopt a solution or not are obviously part of an environment and receive influences of different weight from other people. Here we are considering subtle or indirect influences -not explicit recommendations as those mentioned above- and sometimes not just linked to this specific problem but more general and linked to every aspect of the decision-maker's life.
- The saboteur. Every good play must have a villain, and this case should not be an exception. In some scenarios we should check if someone's motivation is to prevent our solution from being adopted (e.g. because that would question their criteria or threaten their job).
We should always adapt this schema of characters to our problem in particular, because in our case the same profile could play more than one of the roles mentioned above, or some new roles specific to our problem or solution may appear.
Once we have selected the roles that will take part in our "RPG adventure", we'll have to fill in their character sheet (i.e. set up the features of that customer segment regarding the problem we are analyzing), which contains:
- Quantitative data. Here we should identify some socio-demographic features of the customer segment: age, gender, level of studies, income level, residence areas, etc.
- Qualitative data. Our characters' "story" regarding the problem and their motivations: how important/frequent the problem is in their everyday life, what kind of experiences they have lived and what type of solutions they have tried, good/bad conclusions from those experiences, etc.
The key difference (to make use of this analogy to the right extent) is that, when we are putting Customer Development into practice, we should understand that what we are characterizing are just hypotheses, and we must not take them as true facts on which to build our solution unless we validate them by face-to-face interviews with real examples of those customer segments.
[Haz clic aquí para la versión en español de esta entrada]
Normally the decision maker is defined as owning the budget and would be the same as the payer. You can sometimes locate an advocate who has successfully orchestrated the adoption of other methodologies or practices (and the tools to go along with them). They are referred to by various names: internal champion, fox, change agent, or intrapreneur to name a few. They often play a key role for products that have discontinuities with current practice and require a change in internal workflow or process.
ResponderEliminarThanks very much for your comment, Sean. I do agree that payers usually qualify as decision makers too, but it's also true that in some specific environments (e.g. budgeting in public administration) they might be separate roles, hence the distinction. Products for kids also come to mind, but in this case it is debatable whether kids are real decision makers, influencers or simple requesters.
EliminarI really like the concept of change agents, a very useful addition to the "dramatis personae"!