While libraries are essentially service organizations, customers engage with library "products" in their interactions with libraries. Their products include such items as a Web site, an online “room,” a printout of a reference guide, a children’s program – some would even go so far as to say the staff and the physical space are products. What is a product then? According to the American Marketing Association, it is:

1. A bundle of attributes (features, functions, benefits, and uses) capable of exchange or use; usually a mix of tangible and intangible forms. Thus, a product may be an idea, a physical entity (a good), or a service, or any combination of the three. It exists for the purpose of exchange in the satisfaction of individual and organizational objectives.

2. Occasional usage today implies a definition of product as that bundle of attributes for which the exchange or use primarily concerns the physical or tangible form, in contrast to a service, in which the seller, buyer, or user is primarily interested in the intangible. Though to speak of "products" and "services" is convenient, it leaves us without a term to apply to the set of the two combined. The term for tangible products is goods, and it should be used with services to make the tangible/ intangible pair, as subsets of the term product.

Personas provide a means to understand customer and non-customer expectations of products. With this understanding, libraries are able to prioritize trade-offs in product features, content, and functionality throughout the product development process. Personas assist in establishing marketing collateral and in communicating with and supporting customers once a product is launched. In other words, done well, personas clarify who the product customer is, what the customer expects and considers significant, and how the customer can benefit from the product. This third article, the last in a series of three, focuses on the use of personas to define new and improved products – both virtual and physical. The first article covered the basics of personas. The second article explored the use of personas in establishing levels of service.

As part of TKG Consulting LLC’s work with SirsiDynix, we established seven primary personas for the public library user-base within the northeastern United States and part of Canada. While all seven personas had some unique needs in content, features, and functionality, there was a set of common expectations such as online collaboration or social networking; email updates on events, including notification of materials availability; staff knowledge; improvements in search functionality; and easy access to electronic materials – such as e-books, RSS feed, and news. Some of the distinctions between personas exist in terms of how they manage their own library accounts via online account management (think of online banking or Netflix), how they seek out answers to their information needs (such as documentation and tutorials or virtual reference using IM), what types of information they need (news, foreign language materials, community archives) or how they use information (such as in a building or receiving a personalized information packet). Even these distinctions might be of broader interest once their availability is declared.

The reader is likely thinking, “Well, yes – none of these are new ideas, and we have them all the time.” And, the reader would be right. The critical difference is that the requirements are defined by the customer. Defined not via a survey that asks them to respond to a series of potential options that the librarians have put forward, but through a narrative capture exercise that looks at their known information experiences and identifies what works well and what doesn’t. Through a series of hands-on exercises, the participants are able to identify those bits of content, features, and functionality that may not have been obvious, but on reflection form a core of their product needs.

Think about this distinction in terms of Johari’s window – an interesting categorization of how humans communicate what they know – and what they don’t know they know. The narrative capture allows the library to gather not only what is known to the customers, but what the customers don’t know they know. With a clearly articulated set of needs, the product team is able to focus on what the customer has identified. This is very important, as experts tend to believe they know their customer best. How often have experts said that individuals simply don’t know what they need and that the expert does? Personas remove the need for this assumption. In doing so, it makes it much simpler for product teams to remove the discussions reflecting expert opinions and to focus on the customer-identified requirements. The experts can bring to bear their skills and competencies in designing, developing, testing, and deploying a product against the requirements.

Depending on the objectives of the library, the requirements can be prioritized in a number of ways. Several examples follow.

• Through surveys, focus groups, or by mandate from a library board, a library may identify a need to address one product or even one feature. The personas' experiences with the one product or feature will inform priority modifications, including what really needs to remain the same. For example, if all personas find the categorization of specific subject areas or content types difficult to use, it would become a product priority. If only two of the seven personas found it difficult in their information experience, it may be worth exploring, but is not likely an immediate change required. If no persona even mentioned it, it is probably not worth consideration.
• If one target customer group, e.g. high school students, is more important at this point in time than another customer group, the persona representing the requirements of high school students would take precedence. For example, there may be requirements for real-time collaborative rooms with content specifically for high school-aged people, which entail entertainment, social networking, and research features.
• Perhaps the library is seeking to meet the broadest set of needs within a specific amount of time and money. By understanding those requirements that are common across personas, priorities can be set in terms of short-term wins, the requirements considered important, but not urgent, and those requiring a longer term investment.

For example, every persona may want email notification of account information, and this may be an easy win for the library. Or, most personas may want easier access to and management of their own account information, but this may entail more investigation and might be expensive, so it is likely important, but not urgent. Trends may present themselves across personas such as the increasing use of social networks, the expectation of downloading content, or the growth of interactive learning experiences – all of which require a longer term perspective, but not too long, as trends tend to either die or take wing quickly.

• Within the broadest considerations, the library may be completing an environmental analysis and needs to prioritize products in juxtaposition to other information providers. Personas can enable the articulation of expectations of library products in the context of the customers' day-to-day lives. For instance, if the library is to be a community center, the library may take on the role of providing a portal to all community-related information. Or, if the customers tend to use other online information centers, or seek out assistance at their local high school or mall, the library may consider products that fit well with those delivery channels – as standalone products or as parts of others’ products.

Once priorities are set, a product team can get to work. All facets of a successful product have a common starting place – and the prioritized list of features, functionality, and content, along with the persona documentation, provide such a place. Managed carefully, support, marketing, design, and development teams can work simultaneously – connecting as often as needed to ensure they are all still focused on the same set of priorities. Design teams can design; product development teams can develop; support teams can prepare the documentation as required for staff training and ongoing customer support; and marketing teams can prepare the collateral and communication plans.

When in doubt, all teams have the prioritized features, functionality, and content to return to. When in double doubt, they can test the in-process product with a target customer set to ensure it works as designed and meets customer expectations. In fact, this level of interactive and iterative product development with actual customers is highly recommended. It significantly increases the likelihood of success. It enables the library to say, "Others like you find this useful" – and even more importantly, for the customers to speak for themselves.

Personas provide a close look at how users and non-users of library products interact, and wish to interact, with the library. They assist in setting priorities, and in keeping product teams on the same page. They enable product support to communicate effectively with the target customers, and to reach target customers by using their own language in promoting and positioning a product in the context of their day-to-day lives. Personas enable the library to look at their products from the outside in – and to deliver products that are useful, usable, and, most importantly, used.

For more information feel free to contact Mary Lee Kennedy at marylee@tkgconsult.com