Transcription
[Music]
Hello friends, good afternoon. This recording is the complete version of my presentation from the Flow conference in 2022. Today, I want to talk to you about personas and their application in business analysis.
I want to explore together what personas are. Are they just a trendy new term for stakeholders? Or are they something entirely different? If they are different, why do we, as analysts, need them?
The fact is, we have traditionally worked with stakeholders throughout our careers. We have learned to identify them, analyze them, and develop requirements for them at a higher level. We know how to create communication and interaction strategies with stakeholders. The most advanced among us even work seriously with the resistance to change that these stakeholders demonstrate.
One of the important documents we created as a result of stakeholder analysis was the so-called stakeholder list, roles, and responsibilities. At least, that’s what it was called in the second version of Bubble. In the third version, it was renamed the stakeholder list, stakeholder map, or persona list. The guide provides definitions of the list and the personas themselves. However, neither provides a clear answer to the questions: what do we need personas for, how do they differ from stakeholders, how do we define these personas, and what benefits do they bring us, distinct from stakeholders?
I tried to delve into this topic and read articles that were worth it. I bought and read the most significant books on the subject, including the well-known "The Inmates Are Running the Asylum" by Alan Cooper, who actually created the concept of personas.
The results of this analysis formed the basis of a framework I developed for our project work. However, what I want to share with you today is not just an overview of what I read. There’s no real benefit in that since you can find and read all of it yourself if you wish. This is more about my understanding and synthesis of everything I read into a cohesive, interconnected picture.
This presentation will contain a lot of information, many definitions, many models, and practically no fluff. So, if you find it difficult to go through this presentation in one sitting, you can return multiple times to review or finish watching this recording as many times as you like.
To start, let’s recall what we already know, just to align our understanding. Let’s first remember who stakeholders are and why they are important to us.
It is crucial for us to understand who the stakeholders are in our initiative since they play a central role in business analysis. Let’s recall what the guide to the body of knowledge in business analysis says about stakeholders. In fact, the guide is not very verbose on this matter. In the official Russian translation, we defined stakeholders as individuals or groups with an interest in the change, needs, or decisions.
For us, this means certain groups of people in the client company, usually around 10 to 20 individuals, often those recommended or designated by a senior manager on the client side. We understand that they can be different; they may be at various levels of the organizational structure and have different specializations. Some may be purely business-oriented, while others may be more technical.
We know that some are more inclined to work with us, while others are less so, simply because they are difficult individuals. But overall, this is a fairly homogeneous, small group of people we need to interview and gather information from.
In reality, the structure of stakeholders is much more complex, and we will now clarify which categories of stakeholders we need to be aware of. A rational question arises: why do we need to know about these categories?
The fact is, these categories are so fundamentally different that ignoring their differences is like trying to impose one style and size of clothing for all the inhabitants of the planet.
In an interesting article titled "The Complete Guide to Stakeholders in the Workplace," a much more comprehensive definition of stakeholders is provided. Let’s take a look: a stakeholder is an individual, group, or organization interested in the success of an initiative or a specific project. A stakeholder can be both internal and external to the company, and different stakeholders may have varying levels of interest and priorities.
A stakeholder can be influenced by or can influence the outcome of a project or the success of all initiatives. This is also interesting; it’s a very good definition. However, unfortunately, it mixes two completely different approaches to categorizing stakeholders. These approaches are actually at different levels and exist in different universes.
This may sound complicated now, but we will easily sort this out together.
The first level, as mentioned in this definition, states that stakeholders can be interested in an initiative or project. The initiative or project may affect the daily work of that stakeholder, or that stakeholder, due to their formal or informal power, may influence the course of the initiative or project.
What is this? This is the well-known approach to stakeholder classification developed by two specialists from a company called Lucy Consulting Group, namely Peter Simon. We widely use this tool both for identifying stakeholders, as it suggests where to look for them, and for analyzing and categorizing stakeholders.
Since we are talking about categorization, we also use this tool to develop strategies for working with stakeholders who fall into various categories. I repeat, this framework is well-known, so I won’t waste our time discussing it in detail, especially since our discussion today is more interesting in terms of the second approach.
So, the second level in this definition states that stakeholders can be both internal and external. Interestingly, when we come to a client company, if we are working on client projects or internal projects within our own company, we most often study the internal employees of the company.
These are the people who will work directly with our solution, with the platform we are developing. If we study any external stakeholders, they are usually hypothetical external users of the platform we are developing.
Before we take a closer look at external and internal stakeholders, let’s clarify external or internal in relation to something. We need to specify the context in which we define all these categories. The context in which we conduct stakeholder analysis depends on the level at which we are working.
For example, if we are working on business transformation, we will define and analyze stakeholders for the company as a whole. We will look for personas interested in the business overall, meaning we will seek those who have the authority to influence business development or whose work depends on our business in general.
If we are part of a project team, we will analyze stakeholders for the project. In this case, we are talking about people or groups of people who are interested in the project, can influence the course of the project, or whose daily activities depend on the results of our project.
Therefore, for the definitions of external and internal stakeholders, as well as other categories we will discuss later, we will add the definition of external or internal stakeholder of the organization or external or internal stakeholder of the project.
First, let’s look at who internal stakeholders are. Internal stakeholders at the company level are individuals who have a direct relationship with the company through investment, employment, or ownership. They either invest in our company, work for the company, or are owners.
Internal stakeholders at the project level are individuals within the company, employees, volunteers, or team members who participate in creating and executing the project. They work directly on this project.
Here are some examples of internal stakeholders at the project level: project managers, designers, developers, product owners, and so on.
Who are external stakeholders, and should we analyze them? I believe we should, but it really depends on the type and level of our project or initiative.
Let’s look at who external stakeholders are in relation to the company. External stakeholders have no direct relationship with the organization but can influence its actions or, conversely, be affected by them. These include vendors, suppliers, customers, contractors, creditors, and industry regulators, among others.
All of them are examples of external stakeholders at the company and organizational level. External stakeholders at the project level are those who can be influenced by your project or the product being created, but they cannot participate in the process of creating that product.
In other words, these are people who can influence the development of your product or the product may affect their work, but they do not participate in the project. Examples of external stakeholders in relation to the project include customers, retail sellers of our products, suppliers, shareholders, and so on.
We discussed external and internal stakeholders in detail because it is very important to know about their existence and the fundamental differences in their interaction with the business, the initiative, or the project.
But it seems we have covered all possible stakeholders, dividing them into external and internal, and closed this topic. Or are there still some categories of stakeholders?
In fact, within this multitude of stakeholders, we identify two additional subcategories that have their own fundamental differences, so it is necessary to know about them. These are key stakeholders and important stakeholders.
First, let’s talk about key stakeholders. In the third version of the guide, I found about 25 mentions of the term "key stakeholders," but no definitions, only examples, which does not give us any clear understanding of why they are called key.
Key stakeholders are among the most important stakeholders for the company or projects; they are the core of our worldview. So how do we define key stakeholders? The Faculty of Information Technology at the Korneev University provides the following definition: key stakeholders are a subset of stakeholders whose withdrawal of support would lead to project failure.
I made a slightly awkward translation of the quote from the original source, but I think the idea is clear. Meanwhile, the Australian company Mosaic, which provides consulting and training in project management, defines key stakeholders from a different perspective. Their definition states that key stakeholders are those stakeholders who have the power to prevent the project from achieving its goals and can intentionally lead the project to failure.
In this case, the term "key stakeholder" is used to denote members of a subgroup of stakeholders who can consciously and purposefully cause harm to the project and potentially lead to its failure.
The main difference between these two definitions is that the first states that the project may collapse if key stakeholders simply withdraw and stop supporting it, while the second states that key stakeholders have the power to consciously and purposefully cause the project to fail if they wish.
Here’s an example to illustrate this fundamental difference between these two definitions. The definition given by Korneev University is well-suited for internal IT projects, but in the case of more global projects, it can definitely be very misleading, as it ignores important groups of stakeholders who will never be interested in the success of your project.
These stakeholders include competitors or, as described in one of the books, various environmental protection organizations. For example, if you are working on a large engineering project, these stakeholders have significant power and will never support your project. They will do everything to prevent its continuation or, in the case of environmental organizations, at least minimize the successful outcome of the project, such as its impact on the environment.
They may not consider the results of your project as good or desirable at all. That’s why, when building a strategy for interacting with such stakeholders, it is most appropriate to find effective and, I emphasize, ethical ways to neutralize the threat they represent.
It is critically important to understand who the key stakeholders are in the project and how they relate to this project or initiative.
Everything we have discussed so far is, so to speak, static, meaning something relatively stable and slowly changing or not changing at all. But there is also a dynamic component. For example, due to certain circumstances, some stakeholders require our close attention; they are very important to us right now, but only for a limited period.
Therefore, we identify another category of stakeholders that can be part of any of the previously mentioned groups. This category is called important stakeholders. An important stakeholder is one that has been identified as important during a specific limited period.
Importance, in this case, indicates that due to certain circumstances, these individuals need our close attention right now.
To clarify, key stakeholders always represent a potential risk to the project. This can be an opportunity or, conversely, a threat. Remember, we know that the classic definition of risk does not carry a negative connotation; risk is either a potential threat or a potential opportunity.
Thus, key stakeholders represent a potential risk to the project, either as an opportunity or a threat. However, they may not be particularly important at the moment. For example, if the relationship between the project team and a stakeholder is currently working well, the team may not need to prioritize communication with that specific key stakeholder at this moment.
However, some other stakeholders, whether external or internal, may or may not be key at a certain moment in time, requiring our special attention. For example, the information they need to provide may depend on the completion of our plans at this phase of the project, or someone may need to accept the results of our work, but it is difficult to reach them.
Therefore, we need to elevate communication with these individuals to the highest priority to address this issue.
Now, gathering everything we have discussed, we can represent the complex world of stakeholders as follows: as we see, the entire set of stakeholders is divided into two non-overlapping areas: external and internal stakeholders.
Moreover, external and internal stakeholders can be relevant to both the organization as a whole and to a specific project. The core of this world is the key stakeholders.
Thinking about how to depict the importance of stakeholders, I decided that the most successful metaphor would be an analogy with a flashlight that illuminates a certain area of this structure. We see that stakeholders from any category—external, internal, organizational level, project level, and even key stakeholders—can fall into this area of attention.
Having provided this picture of the structure of stakeholders, I want to conclude the discussion on stakeholders. We will return to stakeholders later, but just to summarize, I have only scratched the surface of this vast and fascinating area.
It encompasses processes for identifying stakeholders, defining their attributes and significance, analyzing and classifying them using selected tools, creating profiles of stakeholder classes, and developing strategies for interacting with various classes of stakeholders.
It also includes identifying, analyzing, and addressing fears and resistance to changes demonstrated by these stakeholders. I intentionally left all of this out of the presentation for two reasons.
First, these things are, in my opinion, more or less known and widely used. Second, the goal of this presentation is still to talk about personas and clarify who they are, how they differ from stakeholders, and what additional benefits they bring us—essentially, why we should spend time analyzing them.
Nevertheless, at the end of the presentation, I will explain how to access comprehensive information on this topic to conclude the discussion on stakeholders.
Let’s bridge the gap from stakeholders to system users. I think I won’t be mistaken if I say that the overwhelming majority of listeners today are people working on projects to develop information systems.
These systems have functionality, and the systems have users who use a subset of the available functionality to accomplish their business tasks. The question arises: how do stakeholders relate to system users?
System users are an even narrower subset of stakeholders who will directly use our system. They will be associated with a specific system role.
What is a system role? Formally speaking, it is a set of permissions to access specific functionality and specific data. Less formally, it is the ability to execute certain functionalities that they are allowed to run within that role and the ability to access certain data and perform actions with that data that are also permitted by their role.
For example, one role may only have the ability to view employee data, while another may be able to see, create, modify, or even delete it.
When discussing IT systems, we can say that the goal of these systems is to automate business processes. In other words, an IT system is like a digital model of a business, and a system role is a digital twin of a specific business role.
Therefore, when discussing the mapping of business roles or types of stakeholders to system roles, we can assert that this relationship is almost always one-to-one. That is, for a specific type of stakeholder, a corresponding system role is created.
Of course, there are exceptions where one type of stakeholder may map to multiple system roles. But this simply means that this type of stakeholder encompasses several business and, accordingly, system roles.
For example, we can identify the business role of a department head and the role of a department employee, and we will create system roles with the same names. In this case, the head can perform both their functions and those of their subordinate employee.
Thus, the relationship will be one-to-many: from the business role of the department head to the system roles of both the head and the employee. This means that the business role of the department head can perform both their functions in the system and those of their employees.
In our stakeholder model, system roles are depicted in areas that can include all other types we have already discussed.
Let’s reinforce that almost always, business roles or types of stakeholders map to system roles or types of users in a one-to-one relationship.
Here, we come to a fairly obvious but very important conclusion: identifying stakeholders who will use the system and mapping them to user types answers the important question of what functionality should be developed in the system.
This knowledge defines the system. It is crucial to understand this because the mapping of personas, which we will discuss shortly, to system roles will answer a completely different but equally important question.
Before we begin discussing the criteria for creating personas, the approaches and techniques we can use, and so on, we need to understand the most fundamental thing that defines the concept of a persona.
How is the concept of a persona defined? Alan Cooper, the person who created this concept, said that personas are not real people, but they represent real people throughout the design process. They are hypothetical archetypes of real people.
Thus, the main difference between personas and stakeholders is that stakeholders are real individuals. Even when we talk about a group of stakeholders, we are still referring to a group of real people. But a persona is always fictional; they are imaginary characters.
In one article by other authors describing the concept of a persona, the authors contrasted the concept of an archetype with that of a stereotype. They literally wrote that a persona is more of an archetype than a stereotype.
I sought to understand the difference between archetypes and stereotypes, and many things fell into place for me.
What is the difference between archetypes and stereotypes, and why are personas archetypes? Why should we even care about this?
The concept of an archetype comes from literature, so I will use literary definitions. However, these definitions fit perfectly into our context.
An archetype is a recurring symbol or motif in literature representing universal patterns of human nature. The word archetype also means an original model from which copies are made.
I think that may not be very clear yet, but let’s look at some examples of archetypes, and everything will become clear.
Hero and villain are excellent examples of character archetypes. The hero fights against evil to restore peace, harmony, and justice in society, while the villain is the main opposite of the hero.
We find heroes and villains in many stories. For example, heroes like Hercules, Harry Potter, Frodo, Superman, Achilles, Sherlock Holmes, and so on. Examples of villains include Voldemort, Professor Moriarty, Captain Hook, Sauron, Shere Khan, and others.
If we look at the heroes, we will notice that they have various qualities, belong to different eras, cultures, and periods. Yet, they all share one thing in common. What do you think that is?
They all fight against evil. In other words, regardless of personal, geographical, cultural, or epochal characteristics, they are united by one goal: the fight against evil.
To reiterate, we can group people from different eras, countries, nationalities, cultures, and educational backgrounds into one archetype simply because they share the same goal.
What is a stereotype? A stereotype is a character obtained by generalizing traits of character or external characteristics. In other words, we take real people, generalize their characteristics, and create a generalized image.
This is precisely the character obtained through generalization and grouping based on beliefs, nationality, habits, or demonstrated behavior, and so on. This is everything we ignore when creating archetypes.
Let’s look at an example. For instance, the not-so-smart among us might try to use the rules of creating stereotypes to label others and demonstrate their superiority.
Let’s touch on the most familiar and dear to us ridiculous stereotype: the Russian. Who is this, according to its creators, unburdened by intelligence? It is anyone living in the desolate lands between Europe and Japan, who has a pet bear, constantly plays the balalaika, and drinks vodka straight from the bottle.
So, to reiterate, a stereotype is created by grouping people based on geographical, national, religious, gender, role, and other criteria.
So why are personas archetypes? Because all respected resources defining who personas are and how they are defined recommend using goals for segmentation, that is, for creating personas, and not getting too hung up on visible characteristics.
This is very important knowledge, and it will save you from many mistakes when defining a persona. At least, when I didn’t understand this well, I tried to create personas based on visible characteristics, such as education and work experience, which ultimately led me to a very good realization.
But what do we mean by goals? What specific goals should we identify for forming personas?
As analysts, we develop requirements for the system following the golden rule that requirements should be free from implementation details.
I am not considering clinical cases where immature companies or development teams pressure analysts to write almost detailed technical specifications with fragments of code, request descriptions, microservices, and other technical details for which architects or lead developers are responsible.
For us analysts, the system is a black box, and we describe the required behavior of the system as the impact on the system and the expected reaction of the system. We describe requirements in terms of user-system interaction.
This interaction only occurs when there is a necessity, a specific goal that the user wants to achieve with the system.
Let’s look at an example. Suppose we are developing a portal for buying and renting real estate. People with very different goals may come to the portal. Some want to buy real estate, like a house; some want to rent an apartment; and some have already bought a property and want to find a way to refinance their mortgage.
To achieve these goals, users will require completely different functionalities and access to different data, right?
Thus, in this very simplified situation, based on goals, we can create three personas: the buyer, the renter, and the borrower. This approach to creating personas is called user segmentation.
In fact, this is only the first step, as it is a two-step process. The second step, which will allow us to create a more detailed picture, we will consider in just a moment.
This step of defining goals and creating personas based on them seems quite simple and even obvious. However, in reality, it is not so straightforward with these goals.
First, there is a classification of user goals that describes different types of goals. Secondly, one of these types of goals is called a false goal, which describes a trap that almost 100% of projects fall into when they ignore persona analysis.
I don’t want to delve into the details now; I just want to show you the structure of goals so that you have a general picture. This will be very useful because I am sure that you may not even have thought about the existence of some types of goals.
But now, when you look at this picture, you will agree that they are obvious. You don’t need to read the picture closely; just look at the overall structure, and I will briefly explain each type of goal.
I will start with practical goals, which are represented by the blue rectangle on the right. Practical goals are what users accomplish using our system in their daily work. For example, for an internal corporate system, this could involve operations like processing a purchase, generating a report, or executing a transaction. These are the everyday business tasks of system users.
The next type is corporate goals, represented by the rectangle at the bottom. These are the goals of the organization itself, such as increasing company revenue, attracting more customers, selling more products or services, and so on.
If the system only facilitates the achievement of practical goals, which we discussed earlier, while ignoring corporate goals, the solution will be a failure.
Equally important are personal goals, represented by the rectangle at the top. Unfortunately, we are likely not even aware of these goals, but neglecting them will kill your solution much faster than you think.
The fact is that a person using our system should not feel like a complete fool who cannot understand how it works. They should not constantly fear making a mistake that will be difficult to correct or cost them dearly.
They should also derive some enjoyment from working with your system. In English, there is a good word for this: they should experience some satisfaction.
It may seem trivial, but if a user does not derive satisfaction from working with your system, they will not be able to effectively achieve either practical or corporate goals. This is precisely the situation where we encounter phenomena like resistance to change.
In other words, a person resists the implementation of such a solution.
The last type of goal I mentioned is the so-called false goals, represented by the green rectangle on the left. This is exactly what often happens in our projects when we ignore persona analysis. Analysts, product owners, and often programmers decide that they know better how it should work.
In one of the books about personas, an interesting case from real life was described. A team set out to completely redesign internal applications for corporate data analysis. They developed a very powerful and flexible tool, reminiscent of a wide range of interesting capabilities.
These capabilities could be used in any sequence, allowing for the construction of complex multidimensional data sets and generating reports. The team was very proud when they presented their product to the client.
However, the users of the system received the new solution very coldly because, in 90% of cases, users found it much more comfortable to use a simple wizard with a predefined set of steps to build the necessary report.
This is an example of when a team, excited about the possibilities of implementing interesting technical solutions, applied their goals instead of the goals of real users.
I reiterate that I touched on goals only to give you a picture that, first and foremost, personas are created based on their goals. Secondly, user goals are a complex area, and I have only scratched the surface.
As I mentioned, segmentation based on goals is only the first step and gives us a general understanding of personas.
Returning to our examples of already created personas, we can further segment them. A novice buyer with zero experience in purchasing real estate may come to our site. What will they look for first?
Information on how it all works. They will try to find as much information as possible on how to search for real estate to buy, how to avoid falling into the hands of scammers, how to find a bank for obtaining a loan, how the process is structured, and so on.
On the other hand, if we talk about an experienced buyer who already has experience, the overwhelming majority of what we listed will not be necessary for them.
Thus, even though both a novice and an experienced buyer fall into the same category of "buyer," they will actually use the system differently.
Therefore, as a second step in user segmentation, we can create a more precise set of personas. In this case, the criteria used will be their knowledge, experience, and preferences, which form two important criteria for segmentation.
The two new criteria for segmentation are user behavior and attitude toward the solution. User behavior refers to the different ways of using our solution. For example, some may want to read all available articles first and then receive prompts at each step, while others may want to quickly go through the step-by-step process without being distracted by questions like, "Do you need help?"
The second criterion, attitude toward the solution, refers to how the user perceives themselves while using your solution. They may feel anxious or uncertain about lacking important knowledge. They may fear making a mistake that could be costly to correct, or they may feel confident, knowing the system and the process, with the system helping them navigate through it.
You might say, "All this is great and wonderful, but where do things like user interviews, focus groups, usability tests, surveys, and so on fit into this picture?"
That’s correct. To identify what we just discussed—user goals, behavior, and attitude toward the solution—there are many techniques. These techniques are grouped into two areas and three main approaches.
Again, I won’t delve deeply into this topic now; I just want to outline it to give you a general picture. All these approaches are designed to systematically form and then validate hypotheses about what personas should be in your specific case.
In other words, we form hypotheses about what personas should be in your project. These two areas are called qualitative analysis and quantitative analysis.
Accordingly, the approaches are called qualitative persona analysis, qualitative persona analysis with quantitative validation, and quantitative persona analysis. Each of these approaches involves using different sources of information to form hypotheses and different expenditures of human and time resources.
They are completely different. For example, for qualitative persona analysis, user interviews or individual interviews are the most common form of analysis because it is relatively easy for a company to talk to ten or twenty users.
Instead, some companies conduct so-called field studies or observations, where they observe users in their natural environment, which could be an office, and thus observe their behavior while also asking questions about what business goals they are achieving with the system and how they feel about it.
Additionally, we can use usability testing to observe behavior, although this approach is used much less frequently when creating personas.
The second approach, qualitative persona analysis with quantitative validation, is a slightly more scientific approach to creating personas. Segmentation is still based on qualitative research, meaning we conduct interviews with potential users, but we use quantitative research to confirm our hypotheses.
We often have access to user data, such as what product or service they purchased and how often, as well as what user behavior they demonstrated. Therefore, after conducting interviews with a limited set of users, as in the previous approach, we can form hypotheses about possible personas and then validate these hypotheses using data analysis.
This approach requires greater expenditure of time and human resources. Moreover, it requires the involvement of relatively expensive resources, such as data analysis specialists. However, this approach provides a more accurate picture, especially if we have the opportunity to conduct several iterations of hypothesis formation and validation.
The last approach is quantitative analysis, which is based on using complex techniques for analyzing big data, such as statistical cluster analysis. Within this approach, data analysis is conducted, hypotheses about user segments are formed, and data for each segment is obtained, applying statistical methods of machine analysis to validate your hypotheses.
In other words, we form hypotheses, conduct clustering, gather data on these clusters, and validate our hypotheses exclusively using big data analysis techniques.
It is clear that this approach can provide the most accurate picture, but it requires more time and the use of specialized tools, primarily involving specialists in such a complex field as data analysis and cluster analysis.
Each of these approaches has its advantages and, of course, some disadvantages. It is essential to know them to make the most informed decision about which approach to use in each specific situation in your project.
The loss of knowledge and the use of these systematic approaches to user clustering and persona formation is a separate, large, and very important story. Here, I have only tried to touch on it superficially to give you an understanding of how complex yet crucial it is.
Any attempts to create personas just by guessing or on the fly will, at best, be a waste of time, and at worst, could bury your business.
Again, in one of the books, a case was described where a company asked a team of persona analysis specialists to validate already identified personas. The team conducted an analysis and, in addition to refining existing personas, was able to identify another type of persona.
As a result, the addition of this new persona led to a significant increase in the company’s profitability. Additional work on personas, if we use qualitative analysis, must include knowing how to conduct in-person or online interviews, how to select people for surveys, how to properly formulate invitation letters for such interviews, what questions to ask, and how to process this information.
Unfortunately, the format of this presentation does not allow me to touch on all these interesting and very useful approaches and techniques, so I must move on to the last very important point: the mapping of stakeholders, personas, and system users to one another.
We have seen that stakeholders and personas are two completely different concepts that analyze future users of our solution from entirely different perspectives.
However, we are not going to develop a system separately for stakeholders and separately for personas, right? We need to somehow combine them into one cohesive picture.
Let’s briefly recall what we have already discussed about the relationships between stakeholders and system roles. The goal of IT systems is to automate business processes. IT systems are digital models of businesses, and system roles are digital twins of specific business roles.
The relationship between a stakeholder and a system role is almost always a one-to-one relationship. That is, for one specific type of stakeholder, a corresponding system role is created. There are exceptions where one type of stakeholder may map to multiple system roles, but we will discuss that as well.
Therefore, an important conclusion is that identifying stakeholders who will use the system and mapping them to user types answers the important question of what functionality should be developed in the system.
This knowledge defines the system. The mapping of personas to stakeholders will be somewhat more complex.
Remember, we discussed multi-step segmentation and found that even within one group, such as buyers, we can identify several subgroups that will have the same goals but will achieve those goals through different means due to their varying experience, knowledge, and preferences.
In other words, they will use our systems differently. Therefore, continuing with the example of the real estate sales portal, if we create a type of stakeholder called "buyer," the personas will be much more diverse, and all of them will use the system differently based on their experience and attitude toward our portal and system.
As a result, the mapping between personas and stakeholders will be many-to-many.
How do personas map to system roles? What insights do we gain from understanding personas when developing IT systems?
We mentioned that personas map to stakeholders in a many-to-many relationship. For example, as shown in the diagram, persona 1, 4, and 5 map to stakeholder 1, which in turn maps to a system role specifically created for that type of stakeholder.
Thus, we see that three personas (1, 4, and 5) through stakeholder 1 map to one system role, Hector 6. This indicates that the functions and data available within that system role will be used in three different ways.
In other words, if we said that the mapping of stakeholders to system roles answers the question of what should be developed in the system, thus defining the solution, the mapping of personas to system roles answers the question of how the system functionality will be used.
This, in turn, indicates how that functionality should be implemented. What does this mean? This is the design of functionality.
In this case, I am not just talking about the design of some screen forms. I am talking about design in a broader sense, meaning various implementation options for the same functionality or, in the language of business analysis, various paths to achieve the same business goal using our system.
This is where the importance of identifying personas lies. Without identifying and analyzing personas, the functionality will, at best, be implemented as the analyst wanted, and at worst, as it was interesting or convenient for the developers.
There are also many other aspects where the application of personas allows us to perform our IT work better. For example, we can consider an aspect like development planning.
Let’s use the same example of the real estate sales and rental portal. Imagine a team that did not bother with persona analysis, and we see the following dialogue:
The project manager says, "We need to develop the functionality for buying a house." The developer asks, "To what extent should we develop it?" The manager replies, "Let’s start with the minimum, just the steps in the process."
At this point, the developer rightly points out, "But some buyers may need detailed information, and for some, it will be so critical that they won’t be able to move forward in the process."
The manager, unable to find any arguments, simply says, "Well, we need to start somewhere, so let’s begin with the minimum set."
In this case, the project manager’s arguments are exhausted.
Now, let’s consider the same dialogue in a team that conducted persona identification and analysis. The dialogue is exactly the same, but the last response from the project manager is different.
The project manager asks, "To what extent should we develop it?" The developer responds, "Let’s start with the minimum." The project manager then asks, "But some users may need additional information."
The developer replies, "That’s true, but in the next two iterations, we will develop functionality and data for persona John, who is an experienced buyer. He doesn’t need instructional information; he just needs a step-by-step wizard."
And everything is clear; the dispute completely disappears.
I have mentioned several times that this is a large, interesting, and necessary topic, but I have only touched the surface.
Where can you learn more about this? Of course, you can go through the entire process from start to finish, read all the articles and books, and figure out the material, develop your templates, and try to apply them in practice. Over time, you will understand how it works and accumulate your best practices.
There is a more proven path. I am launching a project to develop a platform for business analysts that will contain all the necessary tools, tips, training materials, and best practices for identifying and analyzing stakeholders and personas.
To make this possible, I am launching a crowdfunding campaign on the Boomstarter platform. You may have a legitimate question: "What is my experience with crowdfunding?" Yes, I have experience.
For several years, I led a project to translate the guide to the body of knowledge in business analysis into Russian. When the project was ready, I launched a similar campaign to raise funds for publishing this book. In just two months, we raised over a million rubles, and every penny went to pay for the work of the publishing house and printing.
Thanks to this, new copies of the guide to the body of knowledge in business analysis are now on the shelves of several hundred business analysts in Russia, Ukraine, Belarus, and Kazakhstan.
On my shelf, alongside this fundraising campaign on the Boomstarter platform, I am starting to develop my author course on in-depth analysis of stakeholders and personas. These are two different initiatives.
However, those who wish to support the initiative to develop the platform on Boomstarter will be able to receive a spot in the course at a very significant discount.
To keep track of the status of both projects, you can join any of my groups, either on Facebook or VKontakte. The group is called "I am a Business Analyst." I look forward to seeing you there. Don’t miss out on these opportunities. Thank you!