Is "persona" really just an academic term you learn in college? Would "customer segmentation based on data" be a more appropriate phrase?
This sort of semantic? nitpicking really isn't my style. But since those who have received investment, gained recognition, and built large user bases think that way, there must be reasons. To sort that out, I'll leave this post as a record of the journey of those thoughts.
Personally, I think a service designed to improve the inconveniences of an existing service is different from a service designed to improve what Hong Gil-dong specifically found inconvenient while using oo. In other words, designing a service based on market (or BM) viability is different from designing a service based on a specific user. Usability and market viability don't necessarily (or automatically) move together. Put another way, "needed" and "profitable" are similar to "different things." The more I explain, the less organized it gets and the more tangled it becomes. To summarize: before designing the verb, we should first think — based on the subject — what adjectives can describe that subject.
HBR 201905~06 | The Age of Infinite Connection
Today, companies no longer wait endlessly for customers to find them. They reflect customer needs as soon as they arise, and even step forward proactively before customers recognize what they want.
To step forward proactively like this, one option is to predict based on data accumulated inside the service, and another is to predict based on users' dispositions. To predict users' dispositions, you could either divide users or behaviors using accumulated behavioral data and predict future behavior based on each segment's data profile, or you could limit the service from the start so that only specific users can use it.
Of course, if the problem the service solves is clear, the service can grow even without a detailed (back-story, background) persona. The place I worked at felt that way. But at some point — especially as the service grows more advanced, more detailed, more multi-functional — a moment comes when you see metrics you didn't see before. This is because service design based on market needs (fixing the pains of an existing market) inherently runs into an issue the moment the TASK it defined as a problem is achieved. It loses its sense of direction. Because it has completed its function. A computer halts when its task is done; likewise, when a service has done its job, there is no reason to keep using it.
But from the moment they notice metrics they didn't see before (during earlier growth), teams start adopting professional marketing. They analyze user behavior patterns. So-called growth hacking begins. Ads are built to funnel in new users, whose every move is analyzed hour by hour. Members with ownership start hunting for the causes. Not only that, they send various push notifications so existing users will revisit more often, and carefully observe revisits, time-on-app, and behaviors to find the causes.
A single user's data consists of many columns. The moment a user signs up, a new record is created, and data about that individual keeps accumulating in the columns of that record. When, record by record, the volume grows to what looks analyzable, segmentation work begins to measure valid customers. Management kicks in.
Ironically, a mood has emerged at startups where personas are seen as old-fashioned, while data is in the spotlight.
But data accumulated without background (story, or persona) is just generic mass data. As I said, services created from analyzing market needs or the pain points of existing services (benchmarking or SWOT) lose their reason to exist the moment those issues are solved. Because they are just a function.
That's why personas are needed. What if a service had been designed from the start not just to improve features or fix the pain points of an existing market, but around a persona named "Hong Gil-nam" who was feeling those pains?
Even after solving the initial TASK, you'd still have things to do — you could set future goals and plans. In other words, you can manage one person's life cycle. For example, a high schooler's biggest goal may be getting into university, but after achieving it, life continues. A service designed to fix flawed English education and actually help with the college entrance exam — after graduation, it keeps pushing the existing user to "come back one more time" to hear more exam tips, while running ads/marketing to non-users. No matter how well you apply growth hacking tools in this situation.. I'm not sure how meaningful that is. It reminds me of the ad that urged users to delete the JobKorea app. If, like JobKorea, your purpose is clear, at some point a decision "not to keep holding the user" is also necessary, I think.
Data collected only through your own service (web or app) can't grow into a narrative. Whether you design personas from data or stack data on top of personas, you need a process to draw out user narratives. The image below shows an individual's spending pattern. A service is just one spot on that dream. Data captured only at that spot has no context. That's why, before we accumulate data or provide features, we must understand the user. Actually, we must selectively accept only the users we can understand. Trying to segment an already massive user base and understand each segment's tendency is either too hard, or, I feel, just an exercise in self-rationalization.
If the organization I belong to thinks personas are "too qualitative" a criterion and won't change its mind, what can the service planner or PM there do? While thinking about this, I got a new insight through HBR.
Applying that to an example draft:
Use a user's pattern for consenting to personal-info sharing as a segment for persona design to make four personas. Put existing user data into those personas. Analyze the data inside. While it won't be neatly aligned with life-cycle, you can at least see the proportions making up each persona. Then draw a journey map for each. The start may be limited to the improved feature, but you can gradually expand to daily, monthly, quarterly, yearly, and even everyday-life scope. This is the difference between treating KakaoTalk as just a free IM tool, a communication tool, or a lifestyle tool.
KakaoTalk may feel too successful, making it seem forced. But there are many other examples. Is YouTube just for uploading and watching videos? Is webtoon just a replacement for comic book cafés? Is a portal just for search? Is a photo app just for taking nicer, cheaper, easier photos than a camera? Is a music app just for listening to more music more cheaply and conveniently? In the past, meeting the function was enough. Even today, you might say "yes" to all the "?" above. If so, keep building it that way. Just as how you choose to live your life is entirely your choice, what reason-to-exist the service you belong to has is also entirely the choice of its members. There is no right or wrong. It's purely a matter of attitude.
