Mini Cooper Persona

Let me start by saying, "I love my Mini Cooper S."  Best-Car-Purchase-Ever. 

When I bought my Mini, the dealer told me there was no demographic particular to the Mini.  I wondered if that was bunk at the time, since all those dealers seemed pretty sure of themselves. Since then, I've wondered if he was telling the truth.  Maybe there was no demographic -- certainly, when I see other Mini drivers waving at me, they appear quite varied in age, sex and interests.  Even if there is no demographic,  it is clear there is a distinct buyer persona for the Mini Cooper. 

I'll call him Fred.

Fred wants:

  • A small, fuel efficient car that supports the lifestyle of someone with a full-sized car.  Kudos to the engineers at BMW for creating a tiny vehicle that fits Fred, a large active dog, a child (or a golfbag) and luggage/groceries inside. The wife/girlfriend fits if there aren't more than 3 bags.
  • A car that helps him broadcast a youthful, slightly hip, alternative, independent and quite fun, attitude -- even if he is none of those things in reality.
  • A very good handling vehicle. Fred can trade a bit of performance and not buy the S or a bit of handling and buy the convertible. If Fred wants the convertible, he must accept a bit of additional weight and stiffness, but less that with most convertible cars.
  • A safe vehicle.  The car aced the safety tests and is manufactured by BMW.
  • Good snow handling. With the money Fred doesn't spend on the Mini, he can buy a 2nd set of rims and snowtires.
  • A price less than $30k.

And Fred is shocked to find the Mini Cooper has all of these qualities in a price/performance ratio that puts any other car being considered to shame.  Therefore, Fred is willing to accept:

  • Traction control rather than AWD (because of the $15k lower cost).
  • Minor finish details (for example, my right heel falls into a hole at the edge of the carpet as I stand up to get out of the car) 

in exchange for the above.

In a nutshell, Fred is willing to tolerate some minor finish details and manage without AWD in order to drive a stylish, safe, classic, BMW performance vehicle that can always find a parking space in the city.  And he still has money in the bank. As long as Mini makes Fred happy, the Cooper S will keep selling.

Managing Your Power Users with Personas

When a power user makes demands, he is often asking for features for:

  • Himself
  • The people he influences, guides, manages or trains
  • His plan in the future of your product

Your company may decide to change their product due to this one user's demands or your company can know their product, market and vision well enough to meet the aspects of the power user's demands consistent with your product's best direction while deferring those that are not.

Well-designed personas are a terrific tool for helping everyone in your company understand and make good judgments about your product and it's direction.  As mentioned in "What Are Personas", a product’s set of  personas may include the following:

  • A primary persona who represents of the primary user of each major interface. The primary persona may not actually represent the majority of users, rather he represents the skills, needs and goals of the primary interface. Not based on any individual, the primary persona must be a robust archetype of real human beings.
  • One or two secondary personas who represent additional users of the each major interface, with with differing needs, skills and goals of the primary persona. The secondary personas also must be robust archetypes of the user base.
  • One or two negative personas who represent requests for needs, skills or goals the interface is explicitly NOT to address. The negative persona can be a stereotype of a user. How well do you need to know a domain you don't address? Just well enough to recognize it.
  • One or two buyer personas who represent the buyer's needs, biases and goals. A buyer may or may not be a user of the product.

Let's look at a simplified automotive example.  Let's assume our company, BR Motors builds high performance minivans. 

Our primary persona might be Lynn.  She's a small woman (5' tall) with 2 children still in child seats, and a St. Bernard dog she likes to take with her on trips small and large. Previously, Lynn drove an Audi sports sedan because: it had a high safety rating - including in non-us offset tests - accelerated well, handled like a dream, and had 4 doors for easy open and closure (remember she's tiny).  The price of the Audi was high but acceptable.  She planned to keep the car forever, but was frustrated because the care broke frequently and expensively.  She has vowed never again to buy an Audi.  BR Motor's minivan will become her primary vehicle.  She's dead set against buying a minivan and hopes to find a high performance station wagon to meet her goals.

Our Secondary persona might be Lynn's husband Michael.  Michael is tall.  He also likes a car with good pickup and handling. Safety ratings and also inherent safety sense of a car are important to him, so he demands good visibility from a car. He will drive all of the family trips because Lynn's driving frightens him. Michael thinks the minivan is cool because it can carry almost anything.  While he won't admit it, he's clear that he doesn't ever want to become the primary driver of the vehicle.

Our Negative persona might be Mack.  He wants a tough and tough looking vehicle for his bricklaying business.

Non-obvious, empowering product facts we can intuit from these personas are:

  • Our minvan should clean easily (similar to the interior of a kitchen).
  • In and out of the minivan should be easy - for a small woman, a tall man, and a large old dog.
  • The minivan should reconfigure drivers easily.
  • The minivan should subtly remain the woman's domain.  (How to accomplish that is tbd)
  • If the demand is for industry - even for dog sitting - that's not the direction BR Motors minivan is going.
  • The minivan must better address the needs and goals of Lynn's family than the station wagon or you won't have a sale.

It's important to be aware that a product's real users - especially the power users - may exhibit the qualities of more than one persona.  For example, suppose we have a user named James who has purchased two BR Motor's minivans for his rural veterinary clinic of 5 people.  He requests the entire vehicle - including the rear - to more disinfectable because he has truly filthy equipment going back there. He'd like better shocks and a higher ride for the dirt and mud roads he travels.  He bought the car for its reconfigurability, flexibility, size, price, and handling.

Using the personas, we can see that James is significantly using the minivan as a Mack.  We can't just discount his requests.  He's a significant buyer and a power user, but we can and must look at his requests to see which will be valuable to Lynn and Michael and which for Mack.  (I can see us making the main cabin of the minivan even more cleanable and perhaps doing work on the reconfigurability of the vehicle, while largely putting aside James' requests.  We know our market.)

With personas, everyone in the company will:

  • Naturally organize and internalize the demands of the power user
  • Understand the priority of each request (high, medium and not)
  • Implement the best features with the appropriate interface. 

Personas are a great power tool to prevent a Product Management Development from chasing sales and from building a product that only one person (says he) will buy. 

Replace This Engine: A Persona Story

WhizApp, the company I introduced Personas to a few years back, reached the business decision (due to financial & legal pressures) to replace a 3rd party engine in their DeskTop product-line with a similar, but entirely different engine from another provider.  The project initially stirred all sorts of emotions and opportunities within the company:

  • Marketing thought it a sad waste of money and energy to gain very little additional product or market features
  • Product Management agreed with Marketing, while fearing the product would lose functionality
  • Development thrilled at the idea of replacing an old, archaic piece of software with one that was more modern and more functional.

The company treated the engine replacement as a relatively pure development project.  Take out the old and put in the new.  Experts in the subject matter were hired to work on the project.  Time and customizations from the new engine provider were part of the deal. Original estimates from development was for the team to finish the work in approximately 4 months.  As anyone not directly involved in the project would suspect, the work was far more complicated than that. 

The engine had UI responsibilities, database responsibilities, and middleware responsibilities.  It touched and affected every part of the product – including a significant amount of documentation and example code. The old engine and the new engine wouldn’t connect the same way, wouldn’t have the same interface, wouldn’t run the same code.  There would be changes. Additionally, the old engine had bugs, but the new engine had different bugs. Finally, the developers wanted to take this opportunity to do better – to do more – with the capabilities of the new engine.  Where to start?  How to get the job done?  The lead developer emailed me a 6-page email of questions and concerns.  Yikes. 

I pulled up our market research on the percentage of users who said they used that engine regularly.  The number was high - 70% if not higher.  This was going to be further trouble, as Product Management and Development had believed that only a small number of people actually used the that part of the product. 

We pulled the product experts (Product Management, including the founder and CTO) and the developers into a room to put together a game plan.  First we discussed the usage data and concluded that everyone was right – always a good meeting conclusion :-) – and restated the facts: Most users used some part of the engine, but the majority of them used the functionality for relatively simple purposes. In fact, because we had excellent personas, we immediately recognized that the usage was split across the personas.  That was good news. 

DeskTop had a primary persona and a secondary persona.  For discussion purposes, I’ll call them “Bonnie” and “Clyde” respectively.  We knew Bonnie had far less technical prowess than Clyde and little ability to try a different route to solve their problem. In fact, we suspected Bonnie barely understood what she was doing when she made use of this engine. 

Impressively, with less than 2 hours of discussion, we had a solid, small, set of persona-based guidelines that successfully guided the release priorities, the development and qa (and helped the marketing) of the engine replacement project for the duration of the project, while also addressing the tech lead's concerns. 

The list looked like this:

Rule 1: Both Bonnie and Clyde use the product to reach a satisfactory outcome. (Duh.) 
Rule 2: Since Bonnie would be thrown off her game by new or different outcome – even if that new result was actually a bit better, our development staff had to protect Bonnie by providing the same outcome as before for the functions that Bonnie used.
Rule 3: Since Clyde was thrilled by and skilled to handle complexities in his work and in our product, he would be thrilled with as much nuance, flexibility and capability as we could provide.  Clyde would respect and be excited by better results and wouldn’t be troubled by a result that was essentially the same as before, even if it was presented differently.  Therefore, our development staff was free to expose and make use of the capabilities of the new engine for Clyde’s use and enjoyment, so long as Bonnie was protected as stated above. 
Corollary 1: We fix bugs whenever possible

These guidelines boiled down to the simple statement of “Feel free to wow Clyde but make sure you don’t break Bonnie.” 

And with that, everyone was empowered.  The subject matter expert developers were able to decide for themselves which functionality Bonnie needed to remain unchanged (or they could ask Product Management if they were unsure).  The business and development priorities were clear and the developers were able to decide for themselves if there was time for a Clyde-wowing feature. 

In the end, the project ended up taking 8-10 developers almost 2 years to reach the point of stability.  But until personas were applied to the problem, the project had been unguided and at risk of spiraling out of control.

UPDATE: I re-read what I wrote hear based on Saeed Kahn's question.  To paraphrase, Saeed asked "Isn't this a case of making sure the old functionality worked for the old users and new functionality would be available for the new and powerusers?"  Here's my reply:

Our solution was different from "the old "stuff" has to work as before, or if it is technically not possible, then an automated upgrade path so the old "stuff" is upgraded with minimal user effort and works."  Though this was my starting position as well on the previous release of the product.  Our product, including this engine, had more subtle implications because it included continuous compile, execute and document. We didn't have a datastore that would tell us the previous output, and since we no longer had the previous engine, we couldn't know what they'd used our software to create and couldn't automate an update.  (Clear as mud?)

Anyhow, this product - while still looking to grow - was funded by the existing customer base which was millions strong.  This engine replacement was due to the collapse of a business relationship with the provider of the previous engine.  So we weren't replacing this engine with an eye to new users. (Though we always wanted new users and did other work to gain them.)

In this situation, the old results were very difficult to duplicate and were in many ways sub-standard.  What we needed to understand was:

  • The combination of compiler instructions must give an end result precisely as before.  (Knowing that each of these was nearly impossible to achieve, so it needed to be as small a collection and combination as possible.
  • The combinations of compiler instructions could work a new way.

It turned out that our persona-based use model captured the situation perfectly.  One persona re-used existing work ad-infinitum (as a sort of robust, qa'd template), so any re-work would affect too many existing projects.  Plus that persona was already over his head with the compiler and asking him to re-implement differently would be disastrous to his work.  Our other persona tended to use our product  The other persona used our product for unique work each time.  He just needed to learn a new way of working.  And that persona tended to be excited by new compiler, execution and documentation opportunities.

We never did and never were able to make a complete list or combination of compiler instructions that needed to work the old way.  We were forced to work on a "I'll know it when I see it" (aka pornography) basis.  Our developers and product managers made good decisions, and then our QA and beta customers second-guessed those decisions until we had done the best we could do.

An additional value of using the personas in this way is they prevented the dev staff from speding all their time on the cool/sexy work they wanted to do, helping them stay focused on the dull/necessary work of the product.

- Bonnie

The Curse of Knowledge

Does your development team:

  • Have similar types of software and hardware expertise?
  • Know your product better than most of your customers?
  • Wonder why the rest of the company “doesn’t get it”?

If so, your team’s high levels of skill may just get in the way of great innovations.  It’s called “the Curse of Knowledge.”

Check out this article in the New York Times called “Innovative Minds Don’t Think Alike", and then consider about your development team.  According to Dan and Chip Heath, authors of a very enjoyable book called “Make to Stick: Why Some Ideas Survive and Other’s Die”, the curse of knowledge is why engineers design products that only other engineers can use. (Otherwise known as why the remote control has 52 buttons.)

According to the article, Chip Heath says:

You have to bring together people with a variety of skills. If those people can’t communicate clearly with one another, innovation gets bogged down in the abstract language of specialization and expertise. “It’s kind of like the ugly American tourist trying to get across an idea in another country by speaking English slowly and more loudly,” he says. “You’ve got to find the common connections.”

In “Innovation Killer: How What We Know Limits What We Can Imagine – and What Smart Companies Are Doing About It,” Cynthia Barton Rabe describes what she calls “zero gravity thinkers” who are corporate outsiders, smart and skilled but with non-identical skills.  She says they are very useful at keeping creativity and innovation on track by looking at the problem and opportunity from new angles.

“Look for people with renaissance-thinker tendencies, who’ve done work in a related area but not in your specific field,” she says. “Make it possible for someone who doesn’t report directly to that area to come in and say the emperor has no clothes.”

For me, this article highlights the value of the Persona within an organization.  The Persona is a renaissance idea.  A solid Persona will certainly show whether or not the emperor has clothes and will then provide a clear language for communication.  While you may need a "zero gravity thinker" to help you develop your Persona, it can save your product from this particular curse.

Paradigm Shifting Personas

A number of people have written asking how to develop personas for paradigm shifting products that take years to develop.  It sounds like people are falling into a couple of common pitfalls:

Pitfall 1: How can I anticipate the technology of the future and my users’ skills with it?
Pitfall 2: How can my users possibly tell me what their needs when I can’t share with them what I am building?

To answer the first half of Pitfall 1, technology can only be anticipated so much.  We know CPUs will get faster, disk will get cheaper and smaller, and data will be more mine-able.  Other than that, most bets are off.  (Though I personally wouldn’t bet against Windows… .)  So, while your technology may be paradigm shifting, ask yourself this question:

Is your product going to make use of existing technologies and existing platforms, such as the Xbox or Windows, or does it require new technologies and platforms like the iPod (which in addition to paradigm shifting interface includes funky heads that park when dropped)? 

If your answer is that it uses existing technologies, then from a technology standpoint I would recommend you work with safe assumptions (never trusting a company’s planned delivery dates for its new products) and create your UI last, over an existing API, so you will have the most modern interface possible.  If you are driving new hardware or system technologies, then drive them to meet the users’ unspoken goals.  For example, I doubt lots of people said, “hey, I get scared when my laptop fails after I drop it.” since that’s expected and frankly understandable behavior of a laptop, but who among us didn’t cringe and pray when we dropped our laptop? So, the technologists who created that new hard drive recognized it as a feature that would address users’ unspoken desires and concerns.

The rest of Pitfall 1 and Pitfall 2 address how to get the users to tell us their needs. The short answer is that they don’t and won’t.  It’s the rare user who accurately assesses the technology, time, resources and business goals of his/her vendor.  And they rarely accurately gauge their own (or their company’s) willingness to pay for a feature.  If we were to build what they tell us to build, they won’t like it and they probably won’t pay for it.  We’re the experts.  The users need us to listen and observe carefully and empathetically so that we develop a product that meets their fundamental needs and goals. There are no shortcuts.

A Good Decision vs. The Right Decision

In model year 1999, Honda Motors introduced the Insight, the first electric and gas powered vehicle in the US Market.  The  Insight is based on the very popular Honda Civic platform.  Over the years, it has won a number of prestigous awards including 3 International Engine of the Year awards, 2 Best Fuel Economy awards, and, in 2006, the redesigned Civic line won the very influential Motor Trend Car of the Year award. The Honda Insight has always has been the most efficient gasoline-powered vehicle available in the US.

The Insight has the features, look and feel of one of the most popular cars in America; it impresses automotive experts and it excels at fuel efficiency – the entire purpose of its differentiation.  Yet, it got rammed in the tailpipe by the Toyota Prius since the Prius' introduction to the market in 2000. 

The Toyota Prius and the Honda Insight sell for about the same price.  They use a different hybrid technology.  (Honda’s is arguably better. It certainly gets better efficiency ratings.)  They’re both family vehicles. They both have very long warranties to reassure the cautious buyer. 

So what accounts for the fact that Toyota sells 5 Prius’ for every Insight sold?  Apparently, it’s that the Honda Insight looks like a Honda Civic while the Toyota Prius looks like nothing else on the road.  When you see a Prius, you know it’s a Prius.

Toyota realized – or lucked into the fact – that the hybrid users/buyers want the world to know that they care about the future of our planet (maybe more than the rest of us) and hope you will consider the joining them in being responsible.

For example, remember Brad Pitt driving up to the Oscar’s in his Prius?  He eagerly talked about the car  with the reporters.  Sure, Brad cares about saving the world.  Does that mean he curtails his airline travel?  Only purchases food made locally?  Makes sure all the materials used on his movie sets are recycled?  I doubt that.  But the Prius gives him the badge of doing good, enables him to encourage others to do good, and actually does some good (so he won’t be mocked later).

To digress slightly, I remember yeeeaaarrrs ago talking to a friend who worked in the creation of paper products.  He told me that recycling equipment was so good that it could produce premium quality recycled white paper that was essentially indistinguishable from the non-recycled white paper.  But it turned out, no one would buy the perfect recycled white because it was too white and they wouldn’t get credit for doing the right thing.  So, to fix their marketing/product problem, someone would dump a box of dirt into the paper goo near the end of the production process so that the final paper product had subtle but obvious dirt specs within it.  Now the paper looked good, and it also looked recycled.

This ego/bragging rights quality of the hybrid buyer seems to have been the critical factor in the Prius’ success and the Insight’s failure.  While the Honda business people and engineers made good decisions when creating the Insight (it's arguably the better car - or based on quality and price should at least have a significant market share), it was the Toyota business people and engineers who had the insight (or the luck) to understand their users/buyers well enough to make "the right" strategic and design decisions such as making the car distinct and recognizable, fuel efficient enough, and price effective.

I write this tome as means of explaining why personas are not just for fine-tuning a design, but may be critical to the high-level decision making and long term vision for a product.

'The Power of The Persona' is here!

Read the hard copy of my 'The Power of the Persona', a case study of persona investigation and application, in your current issue of Pragmatic Marketing's 'Pragmatic Marketer' (not yet available online) or download the pdf from here.

I look forward to your comments!

Making a Great Product

People often talk about the users’ needs, but less frequently discuss the users’ hidden desires or skills. Unfortunately, a product aimed at users’ needs without an understanding of the users’ desires or skills can lead to a product that doesn’t work for its users.

If you think about it, a product's interface is much more than the UI. It's every part the user experiences -- every interaction -- including:

  • Look and feel
  • Performance and speed
  • Actions and behaviors
  • Content

By focusing only on the features necessary to perform particular functions, products can become too technical or too dumbed down for the users (Microsoft Bob), they might not address some of the users’ less obvious needs (size reportedly killed Apple's Newton), or they may confuse the user with an odd mix of too much and too little feature support.  While Bob and the Newton were Hindenburg-like failures, just think of the last product that frustrated the heck out of you. It simply wasn’t well matched for your needs, desires and skills.

Personas are a relatively inexpensive means of communicating the archetypal user's needs, skills and desires to the development staff. Consider taking the time to develop (or hire someone to develop) really good personas to support your current development efforts and increase your odds of building great and successful products.

Does Persona Drive Product Character?

Here’s an idea I’ve been struggling with since learning about personas: does the right persona drive a product’s character?  I think it does.  I suspect that most truly addictive products were built, intentionally or not, with a particular user and buyer in mind.

In thinking about this today, I made a quick list of some current, well-known products that have a strong and broad, positive character:

  • Nintendo’s Wii
  • Apple’s iPod
  • Rim’s Blackberry (or crackberry)
  • Harmonix Music System’s Guitar Hero
  • Intuit’s TurboTax
  • UpToDate’s UpToDate

What’s so special about these products, beside their popularity and a strong character? One thing I notice is that most of these products created a user population where there was none.  For example, before the Wii, video games were primarily built for and played by young males. Yet, when I was a little kid (and bread cost $.05 a loaf … ) the whole family enjoyed Pong. Now apparently whole families are rediscovering the pleasures of video gaming via the Wii.  Even the sound of the name “WEEEE” is easy, family fun.  When I think of an ad-hoc persona for the Wii, I imagine Grandpa and John-boy Walton as great personas on which to base the Wii’s development.

Similarly, Apple (aided by some fantastic marketing) transformed the walkman and mp3 player – typically a young person’s entertainment and escape vehicle – into an entertainment and escape vehicle for everyone who enjoys music, young or old.  Once we get music on the iPod, we are transported.  (Yes, I am still bitter about the nights I lost hacking the iPod’s database to load the music.) When I imagine an ad-hoc persona on whom to base the iPod’s character, I think of Loretta Lynn. She’s a smart, older woman with an encyclopedic knowledge of and an encyclopedic collection of country music. She travels long distances and long hours.  She might have arthritis.  She wants to show off pictures of her great grandchildren.  Flipped around, I can almost imaging an iPod having a persona similar to Loretta’s.  It’s great at what it does. It’s good looking and knowledgeable. It’s friendly. It travels well. It performs for long periods of time.  It’s cool. (Hmm, maybe I should have chosen Bono for my iPod ad-hoc persona?)

I don’t have a famous name to pin to TurboTax.  While the product isn’t new, the  merging of the calculation with the documentation of a person’s taxes without relying on black-box calculations and government forms still stuns me in its brilliance.  TurboTax makes so many of us feel more comfortable, more knowledgeable and more in command of our taxes.  When I consider who TurboTax was built for, I think of a blue-collar entrepreneur named “Al”.  Al wants everything nice in life that Wall Street stockbrokers get and he’s carefully earning his way there with his own contracting business.  TurboTax is like Al.  It is in-control, smart, clear. It doesn’t use buzzwords or complex terms.  It doesn’t expect higher eduction, but it doesn’t condescend to people and it is easy and rewarding to do business with.

These obviously aren’t highly thoughtful personas.  But I think they are interesting examples of how a product and a person(a) can relate.

Cardboard Personas Aren’t Worth the Paper They’re Written On

Many current development methodologies, including RUP and Agile, recommend the use of personas as a means to help developers represent and empathize with the users’ needs, skills, goals, and desires of the product. This recommendation can appear – I don’t know – overwhelming (?), and may not even be possible for someone within development to accomplish, and so is handled as a bit of process to be overcome. Some casual user information is documented; a work environment is imagined; a silly name is chosen. The resulting persona is likely too broad, too unrealistic and 2-dimensional. This is unfortunate, because a good persona is very valuable, while a carefully selected persona or two are worth their weight in gold.

The reason these methodologies recommend the use of personas is because they:

  1. Focus everyone on the team on the same set of user needs, skills, goals and environment
  2. Equally empower everyone on the team to make good decisions
  3. Provide everyone with a common language of the user

A good persona should feel like a real person. They have conflicting needs, unspoken career and lifestyle goals, bosses, spouses and co-workers who influence their options and approaches. From a distance, a good persona is someone you would recognize as human, certainly something more than a stereotype. Up close, a good persona is someone the developers empathize with so well that they can consider and evaluate multiple feature implementation options that would satisfy the persona.

All that said, a good persona isn’t good enough to use in development if his/her needs, skills, goals and influences can be superset-ed by a better persona. Remember, one of most valuable contributions of the persona is to reduce the set of concerns from every possible customer demand to meeting this one (imaginary) user’s needs.

It’s as if:

  • Before you were looking at the people in grand central station at rush hour, while
  • After you are working with one carefully chosen individual from that crowd.

So, one of the important tricks of personas discovery is to carefully choose the one individual whose needs and skills would result in an implementation that meets the needs and skills of the larger group of people. Finding “the right” personas can be difficult, consumes upfront time, and requires a mix of technical, business and product judgment to get right – yet they are well worth the effort.

Your personas won’t change significantly release to release – at least not any more than a real human beings needs might have changed over that period of time. “The right” personas have immediate and longer-term payoffs including improved decision making in development, empowered developers, vastly reduced rework, lowered frustrations and increased productivity.

If you’re still using cardboard personas, you’re shortchanging your development effort.

Microsoft’s “Controversial” Developer Personas

While personas are a very private, internal tool, Microsoft has a nice set of publicly known personas for its programming environments. (Microsoft also has less impressive, far less well-chosen personas for other products.)

Discussed in various places on the web, I have paraphrased the following Microsoft information from its original form on nikhik.net, written by Nikhail Kothari:

We have 3 primary personas in the developer division:

Mort is an opportunistic developer. He creates quick to implement solutions for immediate problems. He focuses on being productive and learns as needed.

Elvis is a pragmatic developer. He creates long lasting solutions within a product domain. Elvis learns about the domain in depth while working on the problem.

Einstein is a paranoid (their word J) developer. He likes to create the most efficient solution to a problem and typically researches the product domain and technology before beginning work on the solution.

While these are 2 sentence descriptions of far more detailed personas, you can probably already imagine how these personas might drive the implementation of a feature.

Nikhail presents the example of implementing security-related controls in Microsoft’s development software. Mort would probably prefer a control that just worked when dropped on the form. Elvis would likely need customization capabilities within the control. He might even want to make significant modifications to its default behavior. Meanwhile Einstein would probably expect the ability to investigate every behavior of the control or might even decide to re-implement its behavior entirely. Given these 3 different viewpoints – or expectations, or needs and desires, or skills and environment – it makes sense that:

  • Mort is the primary persona for Visual Basic
  • Elvis is the primary persona for Visual C#
  • Einstein is the primary persona for .Net

Admittedly, there is a bit of controversy surrounding Mort, Elvis and Einstein. As I read it, some people are offended by the “pigeonholing” of the user. (Those offended are generally users of one or more of these products.) While I don’t agree with the criticism, I acknowledge that personas will always get this rap. Personas aren’t intended to pigeonhole the user. Personas are intended to be very useful implementation guides for the people implementing the product. We must be very careful to never to condescend to the user or their persona. (Remember Microsoft Bob? How about that !@#$ animated paperclip?)

Mort, Elvis an Einstein help the Microsoft developer make good feature implementation decisions in each of their programming environments. As a user of each one of these programming languages at different times and different project needs, I find these personas to be both enlightening and apt as implementation guides, but not as actual descriptions of who I am. I like it when a product works for me!

What Are Personas?

In theatre, a persona (Latin for “mask”) referred to a role played by an actor. In real life, we hear the term to mean the social representation people put on display for one another. In product development, a persona is a detailed representation of a fictitious, yet realistic user who helps us understand the needs, skills, and goals of our real users.

The purpose of the persona is to empower the product decision makers – developers, product managers, marketing and executives – to empathize with the user so they naturally make good decisions for the user and thereby produce a consistent, usable product that meets the users’ needs, matches their skills, suits their environment and fulfills their desires.

Personas are particularly useful to development organizations because they:

  • Bring a common user, his needs, skills, goals and his environment to the entire development team in a life-like fashion which helps the developers make good judgments while working
  • Empower the developers with a carefully chosen user to empathize with, virtually eliminating edge cases
  • Unify the product team around a common, natural language of the user, thus improving the quality and tone of design and implementation discussions
  • Focus the development team on a single situation, empowering the collaborative environment to naturally build a product that has consistent, predictable behaviors and a strong character

Additionally, personas are very useful to marketing as they inform marketing and sales of the needs and biases related to the buyer. (Remember, the buyer isn’t always the user.)

Personas aren’t a one size fits all concept. Every product or product line will have its own set of personas based on:

  • The users
  • The market
  • The buyers
  • The competitors
  • The product roadmap

While a product’s set of personas should be quite small, they may include the following:

  • Primary personas, or the representation of the primary user of each major interface
  • Secondary personas, or the representation of additional users (with different needs, skills and goals) of each primary interface
  • Negative personas, or the representation of users who’s needs, skills or goals the interface is explicitly not going to address
  • Buyer personas, or the representation of the buyers needs, biases and goals.

While it can be a bit of work to discover “the right” personas for your products, I strongly recommend everyone in product development, product management and marketing have a well chosen set.