A case study of how identification and application of personas improved a company’s efficiency and quality, corporate cohesiveness, focus and decision making at every level.
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.
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.
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
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.
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:
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:
Bonnie Rind is the founder of Bonfire Development Advisors, a consulting firm committed to empowering companies to build products people love. Her 20-year career includes senior positions in firmware development, business and engineering software development, project management, development management and product management. She has helped companies grow from start-up to acquisition and IPO, and has managed products and projects for several fortune 500 companies. Her blog is www.productpersonas.com.