So, in the first post on looking at the principles of Alan Cooper’s Inmates are Running the Asylum I summarized the overarching message of the book which is, essentially, “don’t let programmers design your solution.” This applies particularly in Salesforce world, as it’s fundamentally an operational tool–it implements your workflows and processes.
This time we’re going to look at your audience–the people who use the system you’re building. Cooper focuses on the idea of Personas and they play a critical role in delivering a good solution.
What’s a Persona?
There’s a subtle difference between a persona and a person: personas are archetypes–representative examples of a group of people. Superman, for example, could represent a Superhero persona. Not all superheroes are Superman, but they share a lot in common–super powers, a uniform, a desire to perform good deeds, team player, squeaky clean. What about Batman? He wears a uniform sure, and has a desire to do good things but…well, there’s some anger issues here, he’s not much of a team player and he has a really big budget but doesn’t actually have any super powers. Batman is more of an Antihero archetype which is another good one for comic book stories. You can imagine more I’m sure. (Wolverine, I’m looking in your direction too…but we need to move along.)
We’re not fighting crime, were buildng a Salesforce instance so some examples of Personas are going to be:
- Business Development Represtantive (BDR)
- Account Excecitve
- Sales Engineer
- Sales Manager/VP
- Customer Support
and so on.
Personas Need to be Detailed and Documented
So we have a list above, are we done? No we are not!
Personas need to be detailed, they need to be written down and they need to be named. The last point is important–going back to our examples are you going to remember Batman or are you going to remember Antihero? The name helps it stick and make the persona more of an actual person.
Define the Things the Person(a) Needs to Do
Detailing a persona isn’t hard, and the detail doesn’t have to be excessive. If we look at an Account Executive–let’s name her Tracy–for example, we could say:
Tracy is an Account Executive who works with new customers to close sales. They create an Opportunity for each Sale and need to add the products the customer is interested in, when the expect the sale to close and where they are in the sales process. They also need to keep customer information like the address, emails and phone numbers, and the people who work there up to date. Tracy usually work closely with a Sales Engineer to close deals, but sometimes it’s not needed
This is a fairly straightforward example, and you might need more but it gets the idea across. We don’t need to list every single field Tracy updates–we just need a sense of what she does.
We’ll call our Sales Engineer Janet, and the persona description might be something like:
Janet is a Sales Engineer who works with Tracy (and other Account Executives) to help close deals. Janet needs to be able to see the products a customer’s purchasing and the customer information but she doesn’t need to update them. She does need to be able to add notes about the sale.
So, we’ve defined come clear differences–Janet doesn’t do much data entry, that’s Tracy’s role.
We’re not going to go into solution mode right now–not here and not in our project. The point is what they do not how they do it and there’s often more than one how even if there’s only one what.
Document Your Personas
The point of writing these isn’t even to get them perfect. They might even change a bit as you move through the design phase of the project, and you might discover some new ones. The point of documenting them is to make sure you have a consistent reference. Without writing these things down, everybody’s idea is going to be a little bit different. You’re also guaranteed to forget some things along the way. Writing them down means you can refer back to them.
Keep them in a Wiki, or create an Epic, or keep them in a shared Word file. Just make sure you keep them.
Isn’t This a Lot of Work? Don’t I Know These People? We Work Together?
Honestly, at a small enough company you might know this. If there’s only two people in a role why document it?
You might think you’re clear on what Janet’s job is, but everbody else might not be. You also might not know everything, so the documentation process is a way of shaking this stuff out. Writing these things down means asking question and learning things.
Learning things is one of the most important things you can do on your Salesforce project. The product you’re building likely sits at the intersection of a bunch of different processes and departments. It’s not siloed–it’s sort of the very nature of Salesforce. Learn how all these personas connect.
Tricks to Define Salesforce Personas
I put a list up top of some examples of typical Salesforce personas but your language might be different–BDRs and SDRs (Business vs. Sales) in some companies; Customer Support is sometimes Customer Success. Some companies have completely different sales teams for new customer vs. renewals and upgrades (Hunters vs. Harvesters?) So what’s the best way to figure out what they are?
Some people think about the Salesforce objects and who needs to use them. Who’s touching Leads? Accounts? Opportunities. This is a bad idea and–unsurprisingly–it leads us back to our core point of the book: don’t let programmers design software. This is a very programmer way of thinking–it starts with technical things (Note: I am not guilt free on this and don’t claim to be. We all make mistakes. It can even work on very small things but it will fall apart eventually.)
A much better way is to think about the customer journey: when you’re signing up a new customer, what steps do you go through? Who do they talk to along the way? Do some people wear multiple hats? What about the renewal process? How does support happen?
Create a visual flow (I am the biggest fan of Lucid Chart ever.) Use colours in it to identify Personas and key steps. Forget about Plant UML or any other “standard” at this point: focus on clear communication and making it readable. (Define your own standard–it’ll be better than Plant UML.)
In the end, it always comes back to the customer journey. That’s what makes great companies, and a great Salesforce implementation–it will deliver clear benefits to both your customers and your team.