¿En qué se parece el "Customer Development" a los juegos de rol?

Aunque el título del post puede sonar al típico comienzo de un chiste la verdad es que, cuando se trata de explicar ciertos principios de la metodología del Customer Development o de cómo rellenar el bloque de los segmentos de clientes en un Business Model Canvas, la preparación de una partida de un juego de rol me parece una interesante analogía y, a riesgo de caer en el tópico, si nos centramos en el emprendimiento digital puede ser un recurso muy útil para formar en estas herramientas a estudiantes de informática :-)

En primer lugar podemos pensar en los personajes-tipo que rodean al problema en torno al cual estamos "diseñando nuestra partida" y donde nuestra solución/producto tiene que encajar. Para que la exploración del problema sea completa y equilibrada tendremos que extender el concepto de "cliente" considerando diversos personajes o roles que las personas asumen cuando tienen contacto con el problema que estamos analizando y con la solución (o tipo de solución) que estamos proponiendo. Basándonos en las propuestas de Steve Blank podemos identificar esta lista preliminar de "personajes para la obra":

• El usuario. Es quien va a utilizar nuestra solución, el que va a estar delante de ella y va a interactuar directamente. Puede que tengamos que considerar diferentes perfiles dentro de este personaje, ya que las funcionalidades que ofrece nuestra solución pueden estar agrupadas para diferentes roles.
• El recomendador. Este personaje es quien tiene la capacidad de emitir su opinión (fundada o no, por haber sido usuario o simplemente "de oídas") sobre nuestra solución, y por tanto altavoz de las virtudes y defectos de la misma. Clave cuando buscamos un crecimiento viral.
• El decisor. Quien toma la decisión de que una solución se adopte no siempre es la misma persona que la usa. Según el escenario habrá que tener muy clara esta diferenciación para no tener dudas acerca de quiénes son los clientes de determinadas acciones.
• El pagador. Un aspecto clave, y que no siempre recae en el mismo rol, es quién es el que finalmente se "rasca el bolsillo" para comprar la solución. Este personaje está presente tanto en entornos corporativos como familiares.
• El influenciador. Quienes finalmente usan o deciden usar la solución no son entes aislados del mundo y reciben influencias de mayor o menor peso de otras personas. Estamos hablando de influencias mucho más sutiles o indirectas (no tanto recomendaciones explícitas como comentábamos antes) y no siempre ligadas al problema o solución particular que estamos analizando sino mucho más generales sobre todo tipo de decisiones de la persona.
• El saboteador. En toda obra que se precie tiene que haber un villano, y en este caso tampoco debemos pasarlo por alto. En algunos escenarios debemos tener bien presente a aquel que tiene como motivación que nuestra solución no se use (por ejemplo porque pone en cuestión su criterio o porque amenaza su puesto de trabajo).

Siempre tendremos que adaptar este esquema de personajes-tipo a nuestro problema en particular, ya que quizá en nuestro caso un mismo perfil de persona asuma más de uno de los roles antes listados, o tal vez aparezcan nuevos roles específicos del problema o soluciones analizadas.

Una vez que tenemos seleccionados los roles que forman parte de nuestra "partida", tendremos que rellenar su hoja de personaje (caracterizar el arquetipo de ese segmento de cliente con respecto al problema analizado), que se compone de:

• Datos cuantitativos. Aquí hablamos de una caracterización sociodemográfica del segmento de cliente: edad, sexo, nivel de estudios, nivel adquisitivo, áreas de residencia, etc.
• Datos cualitativos. La "historia" del personaje en torno al problema y sus motivaciones: cómo de importante/frecuente es el problema en su día a día, qué tipo de experiencias ha vivido y qué soluciones ha solido utilizar, lo bueno/malo que ha extraído de dichas experiencias, etc.

La diferencia clave (para que entendamos esta analogía en su justa medida) es que cuando estamos practicando el Customer Development debemos tener bien claro que lo que caracterizamos son sólo hipótesis, y que no podemos darlas como hechos ciertos sobre los que construir la solución hasta que no las validamos entrevistándonos cara a cara con representantes de estos segmentos de cliente.

[See here for the English version of this entry]