One of the fundamental principles of building products is that you know whom the target user is before you starting building.
For example, let's consider building an alarm clock for the following audiences/customers:
Blind people
Deaf people
Teenage girls
The general public
It should seem obvious that the resulting product (alarm clock) will be completely different depending on the customer for whom you are building. An alarm clock for a deaf person might feature more pulsing lights, while an alarm clock for a blind person might feature more nuanced sound messages. The conclusion is that a product cannot be categorized as a success without knowing which users it has to satisfy.
One way to ensure that you consider your target customer when making product decisions is to utilize "personas" as part of the decision-making process.
What is a persona?
Imagine that you have defined six personas. In the example above, Tim is one of your personas. It is incredibly valuable that your tech team can discuss options when building the product and ask, "Would this solution work well for Tim?"
Using archetypes this way (i.e., representative profiles like Tim's) means you are less likely to overlook a set of user groups when making product decisions. Therefore, by creating a set of personas or typical profiles, you can make sure that your alarm clock app is right for the people you are trying to design for.
What are the limitations of personas?
You are asked to come up with a set of personas for a certain product. Using your knowledge of the product and its users, you write up a list of five personas with some descriptions and demographics for each. The following questions arise:
Why are there five personas and not four or six?
How do we know that these personas are truly different in terms of their needs or benefits they value?
Is it possible that our persona descriptions do not reveal the real reasons that customers decide to purchase?
Thus far, we have established that:
Having typical fictional archetypical characters (personas) help the tech team to have good conversations and make good decisions about how their product serves customer needs.
Making up a list of these fictional characters (personas) doesn't make sense unless we consider the customers buying factors/motivations (or jobs-to-be-done).
Therefore, the ideal set of personas is one persona per buying factor (or one persona per job-to-be-done). Consider the example below.
If you replace unnecessary factors like "has two dogs" and "has active lifestyle" with "is hungry and needs to eat a snack on the move" and "has to be able to buy it at the local grocery store," then Peter (below) still remains hugely useful as a checkpoint and discussion tool for the tech team building the product. It's just that you include relevant information in the persona's details whether he buys your product (Snickers) or not.
The jobs-to-be-done persona
To create personas that represent buying factors, use the template below to fill out the jobs-to-be-done profiles that represent those who really care about your product.
These are still fictional characters, as you can see by the fact that they have a name (Joe Bloggs), a photo (whichever you choose), and some demographics (typical age, job, etc.).
The distinguishing factor is that each persona should be unique when it comes to jobs-to-be-done and situations (or previous events that led to finding your product). When you construct personas this way, only meaningful characteristics show, and they still fulfill the role of making sure you only build what your target customers want.
Let's recap
Personas are a great tool to make sure you ask "Who are we building this for?" and that your product features map to that user's needs.
Personas are often made up of random demographics (e.g., age, children)
Personas with a different job-to-be-done, are excellent representations of why people buy. It is also helpful to talk about these fictional archetypes as you build products what people want.
