When you should use a role-oriented persona and when goal-oriented persona will work just fine.
B2B and B2C marketing
I've been doing Buying personas for 3 years now. But in 2020 I was invited as a consultant to help with product positioning and messaging for a B2B Thailand-based SaaS. To tell you the truth, my experience with B2B SaaS was not impressive. I worked a lot in B2B sales from 2005 to 2010 while building my content marketing agency but it was not a SaaS experience. When I started coaching and consulting startups I mostly dealt with B2C companies, marketplaces and even DTC startups (the only one from "almost B2B" was a Canadian company in crypto space but they still targeted a lot the end users, though the service was delivered via partners — therefore, they needed to build a B2B sales pipeline too).
Anyways, when I was invited, I figured that it can't be that different from B2C — company's executives are humans too, therefore they have the same implicit motives as we all do, and as long as I stick with the basics – I'll be fine. It did not work out. I crafted a buying persona based on interviews I held plus surveys that the company marketing team ran on their own.
Still, it felt off.
Looking at it we saw a person with very simple motives: get the job done, cover all the bases, do everything by the book, shift responsibility if something goes astray... It was understandable and very human, probably many employees have the same feelings, but we could not quite fit all these with the actions that people took: more often than not they acted NOT according to their implicit motives but, well, not so much against them as according to some other framework.
Goal-oriented vs Role-oriented persona
On the second iteration it struck me — we were using goal-oriented personas that are great for B2C products where we have consumers with their goals, motives and pains. While B2B products should be addressing ROLE-oriented persona — not a consumer but a role in a company's hierarchy. This person as a father of 2 might dream about wrapping up their work in 2 hours and going back home to play with their kids. But as a senior manager they are obliged to stay back and do X,Y.Z. In a sequence that is defined by a company's protocol and NOT their common sense, reasoning or any other factors.
As a result of this use case I started studying role-based personas more closely and found out that they are used quite often too. Especially in service design.
Role-based personas are built in a slightly different manner than goal-driven personas. If in the goal-driven persona it makes sense to focus on the story, specific individual variables like level of tech savviness, emotional state and implicit motives, with role-based persona it makes sense to focus on the process that is aligned with the specific role. For example, the SaaS I was consulting helped companies to speed up time to write down quarterly financial reports by establishing better data pipelines between departments. Basically, every department involved got notified beforehand, collected necessary data and uploaded to the portal. Reports were generated automatically with the data available — financial managers had to do the double-check and fill in some missing fields. Therefore, our basic goal for designing the better customer experience and defining better positioning was to build a persona around the Financial manager role, not around a "37 years old Mr. Subhakaran".
Role-oriented persona framework
1. Specify Role
2. Find Jobs to be done/ tasks
3. Use narrative:
— motivations (what role-based persona wants),
— context (what persona knows or suspects, expects, what insights does they have),
— obstacles (what stops persona from getting what they want)
4. Add artefacts (what tools does persona have)
5. Find out pains (what's wrong with this tools)
6. Calculate resources (what can and should be used to get persona what they need)
We heavily relied on the narrative part in the marketing messaging using words and quotes from real managers and — more importantly — their bosses, who were the main decision makers for this product. But the benefits and value proposition was built around the jobs-to-be-done related to this specific role. Product design, on the other hand, turned out to be very much dependent on Artefacts and Resources — some of the features there were planned initially, were successfully and painlessly removed because the founders saw an opportunity to use customers' internal IT resources. It resulted in shipping the product faster, development time shorter and less expenses for the founders.
When I started analysing role-based persona deeply I figured out that I can actually add emotional and psychological dimension to it — through the JTBD (jobs-to-be-done) section. JTBD is an amazing framework that unfortunately sometimes is confused with the Tasks analysis (and I know some service designers who use Task analysis in creating role-based personas instead of JTBD). Can't say how harmful it is for the resulting service (have never seen a life test where 2 designers use role-base and goal-based persona to design the same service and where the outcome is judged by the actual users). But the point is that tasks are always only result-centred ("I need to do the report") while JTBD are result-oriented and reasons-oriented ("I want to do the report because my boss told me so, and because if I don't do it on time I will be considered unreliable person"). JTBD includes not only functional aspects of the "job" but also social and psychological jobs (what others will think if I do/ don't do this job, how would I feel if I do/ don't do this job).
But I guess I'll have to cover this in some other post:) Stay tuned!