Product Personas

Hitching a Ride with the Kindle

XKCD

Brilliant. (But where's my towel?!)

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 such a vehicle. I get myself, my newfie, my child and my groceries in my Mini.  I can add my husband in if I only buy 3 bags of groceries.)
• 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. (A buyer can trade a bit of performance and not buy the S or a bit of handling and buy the convertible. I wanted the convertible, but noticed the additional weight and stiffness too much to go for it.)
• A safe vehicle.  (The safety tests and BMW's name on the box is good enough for me.)
• Good snow handling. (With the money I didn't spend on the Mini, I bought 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 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 abover.

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.

That "Ah-ha" Moment!

Here's a simplified *before* personas and *after* personas scenario. Download the pdf.

Background:

You and your team are responsible for developing the next generation of WhizApp’s Office Management software, an established brand for office management and accounting software.  WhizApp OM is used in accounting, finance, communications, inventory, payroll and other functions. 

WhizApp OM has millions of users in diverse business environments.  WhizApp would like to be bigger than SAP, but hasn’t managed to be that successful yet. WhizApp markets themselves as offering 90% of the functionality of SAP at 20% of the cost.  In reality, they offer and plan to continue offering less functionality than that. Their goal is for the users to forgive the missing features as inessential while attributing their absence to 10% that makes the software more cost effective.

Obviously, this is a big challenge. How does one determine the “less important” functionality?  Existing users regularly request new features and ask for changes to existing features. Your current interface is old, yet you secretly fear some of your users’ ability to handle significant changes to the application.  To grab more of SAP’s market, you need to add functionality, some of it to delicate parts of the existing product. Furthermore, you have requirements to add new components – such as tracking and logging – to satisfy internal business demands, though these functions have not been requested by any user. 

Problem Summary:

Your task is to develop and deliver a major overhaul and update of the WhizApp OM system in order to keep your company vital and to deliver new, highly competitive features, as yet undefined.

How do you decide what functionality to provide and with what priority?  What features are out of scope? What is the presumed user’s skill level?  Maybe there are features you can remove?

In a nutshell: What will make your users want and be satisfied by the system?

Who Are the Users?

WhizApp OM has millions of users.  You’ve met a handful at customer visits, user conferences and their visits to your office.  They seem incredibly different, and seem to have very different demands for our system. 

Here are a few of the users you’ve recently met:

1) Amy Prott coordinates and oversees payroll, employee orientation and benefits at a large law firm. Her demands on the system can be intense and she has to know she can trust WhizApp OM to work properly.  She says she wishes WhizApp were more like SAP.

 

2) Carmen Bembaron’s work environment isn’t enviable. He handles finance data entry and some analysis.  He relies on a rather old computer for all aspects of his work. He doesn’t create or refer to paper much or work with other people.  Carmen does his job each day. He doesn’t care much about what comes of the data.

3) Sandra Nygun and James Randell work for a large office development firm in New York.  They work in the finance department and often collaborate to prepare reports for their Director. Sandra and James know they are competing with each other for the next promotion.

4) Archie Blair works for an 80-person high tech software company with offices in various parts of the US, plus sales offices in the UK, Germany and Japan. Archie works in a remote office, performing multiple roles for his company.  When he’s in his office, he mans the help-desk, writes white papers, supports sales calls and manages the accounting for his office.  On the road, he does sales supports.  Archie is upwardly mobile and is careful to make a good impression with customers yet willing to create havoc in the office.

The Conundrum:

What features do they need? Where’s the commonality?  How do we understand for whom to build what functionality?  How do we avoid building features for one user with the skills of the other?  How do we prioritize our list of features?

Has thinking about the users improved our clarity? Have they helped us define the system?

The Solution:

Take a step back and assess the problem for the standpoint of WhizApps’ goals, core strengths, the needs of its diverse user base…. Look to create a realistic archetypal user – a persona – who would lead your company to build a product that will appropriately satisfy that diverse user base.

For the WhizApp OM product, “Pauline” is that persona.

"Pauline" works for a retail franchisee.  Her bosses – a married couple who she considers friends - own several of the franchises in the state.  "Pauline" handles accounting and payroll, and ensures the businesses meets all legal and franchise requirement. Her office is modern but basic. "Pauline" is a capable computer user, but not a techie. She trained as a legal secretary, and took her job based on her friendship a friend of the owners.

"Pauline" considers her work-life to be a continuation of her social network and friendships.

"Pauline’s" goals are:

• To earn a living.
• To keep the office running smoothly.
• To help the company thrive while ensuring it survives.
• To be viewed by her bosses and the other employees as a friend and equal.

When building software for "Pauline":

• Realize that her work is:
  • Independent,
  • Non-collaborative
  • Reviewed
  • Depended upon
  • Cost conscious
• Focus on general business features, for both small and larger companies to meet, as her bosses and the company has the requirements of both.
• Build her interface to focus on data collection and analysis. While she doesn’t use reports to do her job, she creates very polished reports for her boss to provide to the franchiser.
• Plan the software for current, not cutting edge, technologies.  "Pauline" can upgrade if necessary.

Persona Benefits:

Now that you know “Pauline” represents your primary persona, you can probably see how she meeting her needs will also meet the needs of the other users in her without the distractions and confusions caused by their differences. Pauline’s environment causes her to have the demands of a big corporate environment (the franchise) and the demands of a Ma & Pa shop (the franchisees).  Her work is diverse, having collaborative components (working with her bosses/friends) as well as significant data entry and data analysis needs.  Franchisees typically watch costs carefully; yet understand that significant capital expenditures are a part of being competitive. 

The only need "Pauline" doesn’t address well is a possible need to have access to the system while traveling.  If such as need does exist – that would require further study on Archie Blair and similar users, those needs and skills could be met with a secondary persona.

This is an example case.  In the real world scenario, a company would surely require at least one secondary persona and perhaps a negative persona to help marketing, product management and development know what to build and how. The great benefit of personas is that - rather than trying to corral the demands of the millions of users – they are a simple tool that guide your team to build products that meets your users’ needs and skills, and your company’s goals.

Ah-ha!

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. 

Intuiting Your Audience

I’ve been meeting with VP and Directors of Development and Product Management of – typically – well-funded, mid-stage startups.  It’s clear to me that these leaders who set the direction of the product are not getting enough time with their customers and prospects. It’s the typical product management difficulty. They want to spend the time with their users and buyers, but can’t find the time to do so. There are just too many other pressing responsibilities; too many fires to fight. Instead these product and development leaders intuit their users and buyers. If you are doing this, my advice is to be sure to:

• Intuit the users and buyers based on reality, not on guesswork
• Ensure the staff have a common intuition of the product’s users and buyers (so the work is at least consistent)

Here’s a quick example:  A, a User Experience expert, inherited responsibility for a relatively technical software product that was OEM to (I’m not making this up) Intuit. Intuit’s users weren’t happy with the user experience of the product. Intuit considered severing the OEM deal, but gave the company a chance to address the issues. 

A began calling users.  It turned out that none of the users A spoke with were technical.  While ideally the user would be technical – even a sys admin, actual use of the product had fallen to an administrative assistant, a marketing person, etc.  Based on more research, A created a robust persona for the UI programmers. The programmers, in turn, quickly modified the interface to meet the needs of the true product users rather than the assumed users. The big OEM deal with Intuit was saved.

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

Help Me Create a Persona Workshop

I’m working on creating a Persona Workshop to help Developers, Product Managers, and Marketing folks:

• Learn about Personas
• Develop some sense of how to (and how not to) identify/ create good Personas
• Understand how to (and how not to) communicate and use their Personas to aid communication and understanding throughout their company in support of:

• Product development
• Product marketing
• Sales
• Services
• Roadmap and planning
• New business opportunities

I’d love to hear from all of you about your persona experiences, both good and bad.  I’ll get the conversation going with a couple of horror stories I’ve heard:

Don’t tell your developers the Personas are quantitatively derived.  Personas absolutely must be based on quantitative and qualitative research, but they are still highly subjective.  A good, useful, Persona reflects your company’s values, your competitors, your roadmap and the real reasons your users choose (or will choose) your products.  So, if your developers say, “What’s the P-value of your hypothesis?” you know you’ve overstepped the scientific bounds of your research.

Don’t make a career out of communicating your Personas’ personalities.  Baseball cards with a picture and some Persona facts – Good!  A blog “written” by each of your Personas – Bad!  If you spend hours each day (or even each week) finding new and creative ways to communicate your Persona’s nuances, your Persona is likely highly flawed because it is failing in its purpose to empower others to understand the character, needs and skills of the users and buyers.  (Also, your management is likely to find better use for a head count.)

Don’t name your persona after someone within the company.  (This one actually happened to me.)  We did our persona research and found some great and surprising information.  The personas lead to obvious resolutions to a number of sticky problems and other intractable were suddenly manageable. We just needed to name our personas.  In a mistake I won’t repeat, I sought input from a couple of senior managers.  One manager was extremely helpful and we used the names he provided.  The other manager suggested we use the (rather unique) name of his new Director of Development.  A bit of bias? A desire to seize control?  Just foolishness?  I don’t know, but it was a political hassle that had to be overcome.

A Highly Gratuitous Posting

I’m in the middle of a big project and haven’t had time to write the posting that is on my mind, so I thought I’d post a pretty funny video of me playing with my young daughter.

Then I got to thinking about how this video could be related to building products people love and I realized that YouTube may be the next great resource for discovering and sharing persona related information. Think about it. You can find revealing information about your target user and buyers from their own videos and you can easily compile and share video excerpts.

My video was taken by Joe Shapiro, a member of the Vermeer development team (which went on to become FrontPage) and now a professional film editor and actor (while continuing to work in technology). I don’t recommend this to anyone without children. But if you do watch it, stay until the end because you might be surprised to see who outsmarts whom.

http://www.youtube.com/watch?v=ULQX7Gf7Bv0

A SportsWriter’s Case for Personas

In today’s Boston Globe, Bob Ryan makes clear the value of the persona for development and marketing purposes in his article titled A Striking Difference in Outlook. 

Well, actually he’s writtten about the differing points of view, skills and experiences of baseball fans and professional baseball players. According to Bob Ryan, the two groups of people will never understand each other, and he makes a great case based on the odd obsessions and lack of contextual knowledge held by even the most knowledgeable fan versus the years of sacrifice, skills, and the never ending procession of games played by an ordinary (yet extraordinary compared to the fan) major league ballplayer.

What if we re-read this article but replaced fan with user and professional player with professional developer?  I think we’d see a familiar picture.  Doesn’t the user try to tell you, the professional developer, how to get it right?  Doesn’t he criticize the strangest things?  The user doesn’t understand the time pressures, the technological limitations, the poor management decisions, the ever-changing resources and the constant demands for more ....

If the professional ballplayer wanted to understand his fan-base, he would do well to develop a fan persona.  Similarly, if the professional developer wants to understand his user-base, he’ll do well to develop a user/buyer persona.  Having a compassionate, consistent, realistic and relate-able grasp of the people we sell to and build for, but just don’t naturally understand, is an important start toward making a meaningful connection.  Or maybe we should  just hire userwriters, the software equivalent of sportswriters, to help explain to our user-base what we do, why and how good we are?  Oh right, we have that - they're our technical writers.  :-)

Let’s go Red Sox!!

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!

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.  In fact, 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.

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!