Using internal staff personas for smoother feature adoption | John's Tips 2024W15
Use these steps to create more robust internal processes for new feature releases by creating and using personas for internal staff members
Why can’t my company’s support staff support the new feature my team built?
Well, did you consider that support user as a persona when you were building the feature? Probably not!
Wait, what is a persona?
A Persona is a semi-fictional character that represents a user type within a targeted demographic, helping guide decisions about product features, navigation, and the overall user experience.
Personas are one of the basics that you see in any tech company that is practicing modern product management. This is generally viewed as good standard practice to be more customer centric and have a customer first approach when building your software, especially when you have multiple different types of end users that will be using your product.
Here are a couple of examples of personas used in job stories (good article on job stories vs user stories here)
For this example, I’ll just consider one of our personas to be the customer admin user of the software in question - with a support angle, as I tend to do.
Admin User
When customizing software settings, the Admin User needs an intuitive interface for efficient adaptation to their organizational workflow.
When facing system errors, the Admin User needs a quick way to report and resolve issues to prevent operational downtime.
But, the list of personas usually stop at the door of your company and little to no consideration is given to the customers of your software inside your company.
Generally speaking, internal personas will be similar from company to company. Here is a list of different personas in an average software company and their “name”. I find names do genuinely help make the personas stick.
Feel free to steal these, they have a bit of an Irish slant too.
Product Manager - Product Patrick
Software Developer - Developer Derek
Quality Assurance (QA) Engineer - Quality Quinn
UX/UI Designer - Design Debbie
Support Specialist - Support Sam
Sales Representative - Sales Sarah
Marketing Specialist - Marketing Michael
Business Analyst - Analytical Amy
DevOps Engineer - DevOps Darragh
Security Analyst - Security Steve
Customer Success Manager - Success Steven
Data Scientist - Data Dave
Now that you have this list (which should be linked from your PRD template - for easy access) lets finally consider adding our support job stories for the two admin user stories above.
When guiding an Admin User through customization, the Internal Support User requires detailed documentation and tools to offer quick, tailored support.
When handling error reports from an Admin User, the Internal Support User needs a streamlined system to log and address these issues promptly, ensuring minimal operational impact.
These user stories help to give you the perspective of people who will be supporting this new feature, and if you follow this process for all the different internal personas, you can ensure you have a robust internal support process in place for new features.
This article is one of my weekly tips, but it is also a part of my Support Driven Development series that you can find here.
For my past tips check out my past posts on Substack or check out the hashtag #JohnsTipOfTheWeek on LinkedIn.