The identification and application of personas improved Development’s efficiency and quality during the first development cycle in which they were used. In addition, the use of personas significantly improved corporate cohesiveness, focus and decision making at every level.
In order to protect the company’s privacy, the names of the company and its products have been changed.
The lay of the land
I was hired by WhizApp Corp., a well-established company with two major products: DeskTop, a mature desktop business product with a substantial number of devoted users in a variety of fields, and DataMine, a server product newly introduced to harvest the content produced by DeskTop.
WhizApp was in the process of transitioning the DeskTop business from a B2C model to an enterprise sales model. Sales of DeskTop ensured the company was profitable each year and the company’s new direct sales team was well compensated for consolidating licenses within an account into an enterprise relationship. Since planned sales of DataMine would dramatically increase DeskTop’s already large user base while also raising the value of the content created by DeskTop, DataMine would make WhizApp a strong candidate for acquisition.
Great staff
The people working at WhizApp were top notch. The departments were staffed with hardworking, creative people. The founder of the company, now in the CTO role, continued to be an expert in his domain as well as in high-tech. He directed the products’ future with cutting-edge ideas and innovations. The CEO cared deeply for the products and his employees. The Marketing people had years of experience with DeskTop. The highly skilled software developers were experts in DeskTop’s subject matter. Overall, the employees were dedicated to the company, the products, and the customers.
Frustrated developers
Most days, product managers spent significant time with the developers in formal meetings or ad-hoc discussions, championing, designing and re-scoping features. The developers had strong opinions on what was best for their product, as well as what was possible, so the conversations could get intense. At times, developers expressed frustration that their feature ideas were not reflected in the requirements.
Although the schedule was managed tightly and significant time was spent in design, WhizApp’s development projects typically fell behind schedule. Even during crunch times, the developers worked a standard day and went home while managers worked long nights and weekends. In a moment of candor, the go-to programmer on the DeskTop team justified his work schedule: the company always had more work than could reasonably be done and all of it was always critical.
When pressured by management to realize too many features, the developers battled back by implementing the features they thought most valuable or most interesting according to their best judgment. In a nutshell, the development staff felt frustrated while struggling to:
- Retain their product standards
- Implement the features they felt were most important
- Receive recognition from senior management for their hard work
Competing vision
In fact, there really wasn’t a shared vision among the executives for either one of WhizApp’s products. The executives regularly debated the value and opportunity represented by DataMine, the best roadmap for DeskTop, the amount to invest in developer dollars for both, and the risk/reward of various product release plans and timelines. The second-level managers also had strong opinions about how to best succeed. As each person lobbied a solution and tilted work just slightly in the direction most representative of that vision, the output of the development, product management and marketing departments became noticeably dissimilar.
Troubling results
DataMine 1.0 had been sent to market with little functionality and an obviously awkward interface. The previous release of DeskTop had been of mediocre quality and was now suffering poor adoption and slow sales as existing users chose to stick with the previous version, and corporations demurred from standardizing on an unstable product. Unfortunately, since DataMine required the newest version of DeskTop in order to function, the overall corporate strategy of selling to enterprise accounts suffered.
Overall, this wonderful company with an established, successful product and another early-stage product (based on a solid concept) was suffering from issues of:
- Conflicted vision
- Roadmap uncertainty
- Poor prior product releases
- Frequent changes to release expectations, plans and schedules
- Developer-chosen features and interfaces
- Dissimilar product-related output from different departments
While I didn’t expect personas to be a cure-all for this list, I was confident personas would help Development and Product Management find more common ground and improve overall development execution.
What is a persona?
In theater, a persona, meaning “mask” in Latin, refers to a role played by an actor. Colloquially, the term is used to describe the social representation we all put on display in daily life. In product management and development, a persona is a detailed representation of an example user.
For our purposes, we create personas, or example users, as tools to represent the needs, desires, skills and environment of one or more classes of real users.The terminology we use is as follows:
- The primary persona is the primary user of the particular interface or entire product.
- The secondary persona is another user of the primary interface, one for whom we will make accommodations so long as the primary persona’s experience is not compromised.
- The negative persona is the user for whom we explicitly will not add product features or capabilities because to do so will pull our product in a direction we do not want to go.
- The buyer persona is the buyer (either an extension of an existing persona or a non-user) whose biases and needs must be addressed in the product and/or the marketing material.
These personas enable us to make appropriate decisions when building and marketing our products.
Getting to know your persona
While a persona isn’t a real person, he must feel like a real person to everyone in your company. Therefore, in addition to facts related to his use of the product, we must have basic knowledge about our persona including his:
- Name, age, and education
- Socioeconomic class and socioeconomic desires
- Life or career goals, fears, hopes, and attitudes
- Reasons for using the product
- Needs and expectations of the product
- Intellectual and physical skills that can be applied to the product
- Personal biases about the product or product space
The key to making a useful, valid persona is:
- She must be carefully created during a discovery process that includes interviewing actual users and company employees exposed to the actual users.
- She must be consistent and lifelike.
- She must represent the most useful class of product users.
In other words, the persona must be a well-described, archetype of a user group. You know you have a valid persona identified when you can imagine working alongside him, spending time with her, or encountering him while out shopping. In fact, you’ll know you have your persona nailed when you recognize her at a user function.
The power of the persona
Once the company internalizes the personas and how they relate to the product, these personas guide Marketing and Product Management in simplifying and clarifying product documentation such as the product roadmap, requirements documents and marketing material.
By looking at the product and product plan from the persona’s point of view, communications become more straightforward because:
- Superfluous information and over-specifications can be eliminated
- Features are prioritized according to the persona’s values
- Product messaging can focus on the product’s value to the buyer persona
Personas are especially powerful for development teams. Once developers get to know these carefully chosen example users, they gain an ability to put themselves in the persona’s shoes. This new empathy empowers them to:
- Understand requirements with less detail and specification
- Make good, reasonable implementation decisions independently
- Raise valid concerns and opportunities
- Stay focused on the real requirements and avoid being sidetracked by edge cases
- Feel satisfied they contribute creatively to the product
- Talk amongst themselves and with the rest of the company using the common language of the persona and his needs
Overall, as each employee becomes acquainted with their product’s personas, their work reflects that knowledge, and the collaborative result is a satisfying product and improved product communications.
Common objections to personas
Most current development methodologies, including Agile and the Rational Unified Process, as well as some marketing methodologies, such as Behavioral Marketing, recommend persona-driven approaches. However, people often initially doubt their value.
- Sales and Marketing may be concerned that attempts to build the product for a particular user would limit or bias the product away from the many other fields of use.
- Development and Product Management, especially those already using use cases and scenarios, may object to having more process and more paperwork associated with their jobs.
These common concerns can be allayed. The purpose of the persona is to unite the developers’ image of the user on a carefully chosen, realistic example to support their efforts and natural desire to create a product that satisfies the user. An appropriately chosen persona guides the product to address the common needs of the users, while taking nothing away from any market segment. A similarly well-chosen buyer persona helps Marketing understand and address the needs and biases of the buyer, again independent of market segment.
While personas are different from use cases and scenarios, they can be used to derive excellent use cases and scenarios or even replace them. By putting themselves in the persona’s shoes, product managers and developers can think through the user’s needs more realistically and nimbly than before. This empathy vastly reduces the need for overly detailed documents while also preventing off-target and inconsistent implementations.
Discovering the right personas
Back at WhizApp, I had permission to proceed with the persona discovery. To identify the most useful personas, I first interviewed current, prospective and former users as well as company managers and employees. Just as software development is a combination of art and science, so is persona discovery.
In addition to intuiting the users’ needs, skills, desires and environment, choosing the right personas requires an understanding of:
- User interface design (particularly matching interface to user skills and needs)
- Product development and planning processes
- Technology and product development tradeoffs
- Business and sales
- Human psychology
At WhizApp, I learned a great deal from the user base and from company personnel. As anticipated, the personas seemed to have been waiting for us to uncover them. Within a short time, I had a solid description of:
- The primary persona, one secondary persona and one negative persona for DeskTop.
- Two primary personas for DataMine (one was the primary persona for DeskTop) and a rough outline of the buyer persona.
Introducing the personas
Now that I knew the personas, I set about introducing them to a few of the managers. The reception was very positive. Each manager recognized the personas. They seemed to have mapped the customers they knew, the demands they heard, and the environments they encountered directly onto the appropriate persona and they agreed with the descriptions. In fact, they were excited!
As the personas were more widely introduced, they became enriched with further persona details based on others’ experiences with the users. One very powerful contribution, for example, came from the customer support manager. She pointed out that the secondary persona rarely called customer support, preferring to develop more personal—and hence more influential—relationships with the development and marketing staff.
Although that seems like a small detail, this user-initiated difference helped explain how WhizApp personnel had arrived at such differing views of the users’ needs. They had talked to different user groups—independent of market segment—and that difference was captured in the personas.
Next, it was time for me to share the personas with the entire Development team. That introduction went smoothly as, once again, the personas were persuasive. The developers immediately realized that many of the user requests they had perceived as contradictory or otherwise confusing, made sense in light of the different personas and their different environments. The developers’ only questions were on how best to apply the personas to their work.
A sea of change within the company
Over the next few weeks, each WhizApp department internalized the personas and considered how they could be used to improve the focus of their work. The CTO began communicating the corporate vision and roadmap in the language of the personas. Based on the personas, Product Management quickly understood why DataMine’s interface wasn’t resonating with users. Development agreed and quickly proposed good solutions. Marketing used the personas to clarify their image of the DeskTop users and adjusted the DataMine messaging to better address the buyer persona’s concerns.
Soon, almost everyone in the company spoke, or at least understood, the common language of the personas.
Building better products
The personas were particularly beneficial to Product Management and Development.
- Product managers constantly used the personas to consider feature requests and to communicate the products’ values, needs and opportunities.
- Developers incorporated the personas into their daily lexicon and work habits to design and implement features they knew would satisfy users.
- Contention between developers and product managers eased as the groups worked together to synthesize how best to address the personas’ needs with the time and technologies available.
Over the course of the next release cycle, the WhizApp product team experienced many valuable persona-related improvements, including:
- Clearer and simpler product requirements, designs, and test plans
- Developer-led implementations that improved initial designs
- Better adherence to plan and schedule
- Substantially improved product quality
- Final products that met the initial release goals
Overall, the application of personas at WhizApp led to more agreement of plan and purpose among the company’s very capable staff, more productive development cycles, and the delivery of products that met the goals of the release as well as the users’ needs and expectations.
Two years later
WhizApp was acquired shortly after the introduction of personas. WhizApp’s CTO told me the personas impressed the acquiring company’s executives by convincing them that WhizApp knew its users, their needs and how to meet them.
As time goes on, the usefulness of the personas has not dimmed.They remain a primary, critical tool for identifying and communicating feature requirements, designing and implementing those features, and communicating the value and direction of the products over time.
One of the WhizApp development managers recently described the use of personas as a “fantastic cultural phenomena.”
When to use personas?
Personas enhance focus, communication and collaboration on any project. As we’ve seen, you should particularly consider using personas in your company when there are conflicting visions of the product, when you experience difficulties in communication between Product Management, Development, and/or Marketing, or whenever your products seem to be falling short of your users’ expectations.
