Product Personas

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. 

Work/Life During the Dot Bomb

Have you read “And Then We Came to the End” by Joshua Ferris? 
It’s (significantly) the book I tried to write during that era, but far far far better than I could have done. It’s amazingly well done. Despite being a book about work, “And Then We Came to the End” is a riot. And it’s uplifting.

Its about people in the marketing department a marketing firm getting crushed by the recession.  It seems that the work life of a ad agency creative is quite similar to a programmer’s work life:
All that work just to get to the work; the work of making work interesting; the work that goes no where; the changes that make the previous work irrelevant; the work to prime the pump, plus work relationships, biases, prejudices, jealousies, strati and perspectives that change in less than the blink of an eye.

Getting people to want to read about the workplace is a tough nut to crack. Joshua Ferris has made a creamy butter of it.  (He even added a character who is trying to write an interesting workplace novel.)  We all spend too much time at work. This book helped me appreciate why we do it.

A Moment of Horror

I met a friend for drinks to casually brainstorm on her company’s brand image. I sat down, ordered a beer, some appetizers. We chatted.  Eventually we got to the subject of the brand. 

She handed me a typewritten paper with notes written over the text in places and in the margins. Her hypothesis is that her new brand should be created like a persona.  This is akin to my conceit that product should almost be it’s own persona.  (Hence the name of this blog.) I respect my friend a lot.  She has of integrity and professional follow-though on her idea.  She’s currently working for a B2B consulting firm.

So finally, feeling the drink just a bit, I looked down at her page. 

To:
·    Men, aged 30-59, who are ambitious/resourceful/efficient/punctual
·    Who presently spend a lot of their time in their car, generally enjoy driving, and often find themselves in unfamiliar territory or unforeseen situations, and ..

The page swam beneath my eyes.  I felt myself flush.  Ugh.  Wrong. Horrible.  Wrong.. Ugh.

I said, “Um..”  Then, I looked back down at the page, there was something about those handwritten notes….

Ohh. I exhaled.  The notes were good.  The notes concerned buyers concerns and needs. Ohhhhhh.  My friend was using an old B2C brand statement as a template. Whew.

What if I don't know my User or Buyer?

A few days ago, I gave a talk on Personas and Agile Programming. My audience was a mixed group:  Programmers - Agile & not, implementation folks, support people and a couple of company VPs. The talk was a bit less 2-way than I would have preferred, but that tends to happen when VPs are in the room.  Overall, the group was very receptive and they appreciated the inclusive nature of Personas.

The company has one solid, legacy, product line. They've begun creating new products for users in domains very near their area of expertise, but not within their expertise. Put another way, they have perceived a pain, or maybe just an opportunity. However, they don't know their user or the conditions that will drive a purchase.

"Should we build a Persona?", they asked. Yes! Absolutely! Of course! 

Here's how to proceed when you have access - even just peripherally - to your future users and buyers:

1. Build a straw-man Persona.  I don't love ad-hoc Personas, but they're a perfect starting place. Each lead should put to paper their biases, guesses, best thoughts on who will be using and who will buying the new product. Then swap the papers. 
2. Learn from the other user and buyer experts within your company. You've looked at the other guys straw-man persona. Talk to someone in Support. Talk to Sales. Once you've seen that your view of the users and buyers is different from other experts' views, talk out the differences. What have you learned? How would your new product differ if the user or buyer were like her straw-man?  Can you build a new straw-man persona? If so, do it.
3. Visit the users and buyers you do have access to.  Since the users and buyers of your current product are your leads to the users and buyers to the new product, grab those leads. Go visiting. You don't have to say much or anything about your new product line. Just take a look around while you're there.  Do you see anyone who looks like your persona? Did your imagined persona work in an environment like this? I bet s/he probably doesn't. For some reason, we all idealize, generalize, overlook. Now you can make very important improvements to your straw-man persona.

Are you done? Sadly, no. But you do have a somewhat refined ad-hoc persona. Not as good as real, robust persona based on market research and deep knowledge of your user or buyer, the straw-man ad-hoc persona is very useful. S/he will ensure everyone on the team moves in the same direction - making your team more cohesive and efficient - and everyone on the team will immediately recognize when true user and buyer information shows up that grows or alters the persona.

Creating, refining  and working with ad-hoc or straw-man Persona takes guts.  It requires the management to admit to themselves that there are some things they just don't know. 

Marketing Jobs or How to Assign a Product Owner

Has everyone noticed how many open marketing jobs there are out there right now?  Apparently, in addition to being a country of blackjack dealers and security guards, we're a country filled with something to sell - if only it were pitched right.  Such is the current - hopefully modest - recession.  These ads for marketing people are  for VPs and entry level, not too many in the middle.  It seems that some of these companies feel the need to revamp their overall approach while others figure more marketing is better marketing.

Applying this experience to the world of software development, maybe its not so different from boom times.  Everyone has a product to build/ is founding a company/ is a VP of something development related.  In a boom, entry level programmers are "senior" and the number of engineers on a project is the primary indicator of its success. 

Right now, software development professional are doing pretty well.  The work seems to be there (when you finally get past, or manage to avoid, those automated technical interview test programs). The current trend toward Agile development methods is making our business vastly better.  Agile gives everyone an opportunity to build a success. Agile also exposes everyone.

The toughest part of successfully implementing Agile may be successfully finding the "product owner" on an Agile team. It's typically a product manager who gets the job.  As the product owner, s/he represents the company's executives, visionaries and high-level decision makers on the team.  As product owner, s/he must know, very specifically:

• Who are the largest, fastest, and most devoted group of buyers, and
  
• What are their skills, goals and desires?

i.e. Tell us developers our market; tell us what will motivate a purchase; and describe the true needs of our users. 

Can your product owner do that?  Is there anyone in your company who can?  Does the answer remain constant for more than a month? 

Agile exposes everyone.

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.

Corporate Grief: Could This Be Your Company?

I recently had lunch with a consultant friend recently to share ideas and experiences.  I talked about some of the unexpected (to me) elements of blogging, my recent work and a couple of good prospects.  She told me about her her current client. 

Despite the intelligence and friendliness of each individual, as a group, the client employees were so defensive, ineffective, and frustrating that my friend and her staff began identifying them by their stage of grief.  Apparently, her last meeting was with Anger, Denial and Depression.

My friend said she was conflicted, but essentially eager for her current job to finish up.  She, at least, had reached Acceptance.

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

Re-Writing a Mature Application: How to Succeed

Most people think about new markets and new users, but the fact is that mature products sell to existing customers, plus anyone new.  These existing users (a.k.a. the people who keep your company afloat) have habits, expectations and – most importantly – integrations and legacy data.  These users expect to continue using a new version similarly to the way they used the previous version.  They’ll adjust to UI changes, but they won’t adjust to existing integrations or data being broken.

In addition to great project management and great developers, to successfully re-develop a mature application, I recommend you meet the following terms and conditions:

The application’s features and actions must be well known, well documented, and easily understood by the developers
If the developers don’t know exactly what the feature currently does, how can they redevelop that feature to perform all of the same functions?  ‘Nuff said.

The application must not have undocumented features which are regularly exploited by customers
I’ve worked for companies where the employees believed that by refusing to document an unintended (and often dangerous) product feature, they were refusing to condone its existence and use.  Well, maybe that’s true.  But if you don’t quickly plug up that opening, users will exploit it. Again and again.  Soon, they’re relying on it.  So, if you develop the new product without this critical, undocumented feature, no one will use your new product.

Existing features must not be re-implemented to work differently, unless differently is defined to be a superset of the previous behavior.
The user can learn a new way to do something.  But if he can no longer accomplish something he needs to accomplish, he’ll refuse to use your upgrade.  Better isn’t good enough.  You need to offer everything you offered before and then some.

The Engineers must be eager and able to refer to the original product’s codebase during the implementation process
No matter how good your documentation is, nothing can speak nuance as clearly as the code.  In what order did the rules execute?  What happened when no such conditions were found?  What were the minimum acceptable data elements? These sorts of questions and many others are best answered in the existing implementation.

Don’t end up with customers who refuse your product.  Check out this post from Coding Sanity about “Upgrading” from Vista to Windows XP.

What’s Good for the Gander Might Eventually Be Available to the Goose

A friend of mine recently had his first baby.  He’s a middle manager at a good-sized technology company.  My friend made an arrangement with his management to work 4 day weeks for an extended period of time so he could spend more time at home with his child.  This post isn’t about kudos for my friend who wants to take on bigger than usual burden of childcare, this is about the deal he negotiated at work.  My friend is continuing to receive his full salary for 4 day weeks. 

As is obvious from my use of pronouns, my friend is male.  But even if I had found a way to hide the pronoun, has anyone heard of a woman getting such a sweet deal?

Yes, his boss, (probably sternly) said the familiar, “Make sure you get all your work done!”  But he’s getting paid.  Everyone I know, including me, got the pleasure of getting all of our work done for considerably less pay and often no benefits. Just to be clear, my friend isn’t using vacation time here.  His deal to “work longer days”, though like most people working in technology his day pre-baby were essentially endless already.

Am I upset that a man is getting a deal that women never seem to get?  Yes and no.  No, I’m not upset or jealous about my friend’s arrangement.  I’m very very happy for him.  His excitement about his child is wonderful. And I think the arrangement is a wonderful opportunity for the entire family.  But, I’m very sorry for us women who have to continue to doing more for less. 

On the bright side, my friend’s great deal is surely good news because – just a Sandra Day O’Connor made a practice of fighting for equal rights for men to get those laws and traditions “on the books” – this deal, should eventually lead to equal opportunities for women. At least for women within that company and department.  (Of which my friend said there were “maybe 2”. Sigh.)

Should We Re-Develop Our Entire Application?

Apple'€™s Christmas ads to "Give up on Vista"€ once again got me thinking about whether a company with a mature commercial product has a greater chance of success by:

• Re-developing its entire product

        or

• Re-developing components of the product in a piecemeal fashion

The opportunity to re-build an application under new, modern, technology conditions is seductive.  It'€™s the chance to build the best application everyone can imagine.  The technical staff will make better architectural decisions, eliminating those too-expensive-to-fix bugs and making future enhancements easier.  The UI will be modern and useful.  The code will be clean and supportable.  The product will be better product able to reach further in the market because it can integrate and interact with other programs and technologies built on the newer platforms.  Marketing will love the new product. They can put "€œNew & Improved"€ on all the packaging; they can show off the new interface in pictures.  The entire company will be proud to have a product far better than the competitors'€™ have. 

Meanwhile, modular re-development is limiting.  Developers can'€™t necessarily choose the latest and greatest technologies.  They have to work within the existing architectures and existing limitations of the product.  Most of the current bugs will remain bugs.  Users will be pleased with the improvements but still be frustrated with the overall product.  Marketing will want to know why more couldn'€™t be accomplished.  Everyone in the company will want the technical staff to "€œdo more".

In my experience, wholesale re-development is often a dream that turns into a nightmare as the re-development gets bogged down under the sheer weight of (and the mention inherent in) implementing all of the infrastructure, features, and enhancements of the mature product.  The project gets off schedule and eventually the company is forced to release something that isn'€™t nearly as good as the previous product. 

The reality of modular re-development is accepting incremental updates over time, eventually replacing the entire product so that little of it is brand new and little of it is incredibly old.  (Similar to the maintenance of an aircraft.)  Developers may feel frustrated and disappointed at the start of the project (rather than mid-way through). But, the company's risk is significantly limited.  With a piecemeal approach to re-writes there are fewer dependencies on unknown, un-built parts of the application and fewer moving parts.  The new code will be written.  It will be fine-tuned.  It will be integrated or sometimes grafted into places. (The Bionic Man vs. Frankenstein.)  Even if the worst-case happens and the module gets off schedule and the company forces the release, at least only a part of the application is imperfect rather than the entire product.

Neither of these options seems too encouraging. To be fair, technical development is always a challenge.  That'€™s why we make the big bucks. Good development is about making smart, sometimes daring and sometimes unpopular decisions. Don't let a a re-development effort provide your competitor with the perfect opportunity to steal your market. 

I suspect Apple is feeling pretty good about itself right now.  Certainly all its shareholders are.

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.  Maybe 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 you from the curse.

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

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 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!

What Makes a Product Great?

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

Is Stella a Famous Persona?

I was out with friends recently and found myself recounting a phone call I’d gotten many years ago.  Here’s the text as I recorded it shortly after the call.  I used it as the first scene of my 2nd , unpublished, novel. My friend Amy suggested I rework it as a short, New Yorker-type story and I just may do that.

Stella was sitting on the front porch watching the afternoon traffic pass by when I got the call on my business line.  It was the call I always knew would come.

“Hello.  May I speak with Stella, please?” she said.

“Sure. May I say who’s calling?”

“I’m looking for Stella Woronoff.  W-O-R-O-N-O-F-F,” she said.

“I’m Bonnie Woronoff,” I said. “May I ask who’s calling please?”

“Dunn and Bradstreet has business with Stella,” she said.  I thought her reply a bit haughty. 

“You have business with Stella?  May I ask what kind of business?”

That caused a slight chink in her armor.  “I’m not sure,” she said.  “It doesn’t say here.”

“But you're sure you have business with her?” I said.

“Yes,” she replied, “it says something here about Stella Bear.”

“Stellabear.com,” I said.  “It’s a website.  You have business with Stella regarding stellabear.com?”

“Yes.”

“And you've done business with Stella of stellabear.com in the past?”

“Yes.”

“Well, that's very interesting,” I said.  “I didn't know she was working with Dun and Bradstreet.  Hang on.  I'll get her.” 

I paused a moment, debating…. 

“There is one thing I think you should know,” I said.  “Stella’s a dog.  She’s a big beautiful Newfoundland dog.”

“Oh,” the woman said, though she was dumbstruck only momentarily.  “Is she famous?”

I was impressed by the nimbleness of her response.  Then I realized the woman was entirely serious. 

“Famous?” I said, “What do you mean?  She's pretty popular in the neighborhood, but I wouldn't say famous.”

“Is she famous like Morris-the-Cat or Lassie?”

“No, she’s not famous,” I said.  Then a thought occurred to me.  “Why?  Do you have connections?  I think she should be famous.”

“Uh, no,” the woman replied sounding neverous.  As if I were stalking her. 

“Let me just update her file,” the woman said. 

Damn, I thought. I’d frightened her.

“Is there an option in the file for ‘dog’?” I asked.  As a developer of business systems, I was curious.

The woman then cited my address in Lexington, MA.  “Is that correct?” she asked.

“That’s where I live,” I agreed.  “Stella has a small apartment out back.” I admit it. At that point, I was just messing with her.

“Huh?” the woman said.

“Her doghouse….” 

The woman quickly thanked me for my time.  I thanked her for calling.  When I finished laughing, I joined Stella on the front porch.  She wasn't interested in the story, but she rolled onto her back and let me rub her belly.

Read "the Power of the Persona" in September

Last month in Why a Blog on Personas?, I mentioned a case study I wrote called "The Power of the Persona" to be published in the Pragmatic Marketer, anticipated for August '07.  The current info is that subscribers should be receiving the magazine at the begining of September.

If you are not a current subscriber to the Pragmatic Marketer, you should be. As a Product Manager, I learn something new, thoughtful and/or applicable from each edition. My developer friends seem to appeciate the magazine too. (btw, it's free.)

But, Do Techies Know Their Product Roadmap?

In my previous post, I wrote about my surprise upon learning that the vast majority of my developer and development manager friends believe they have a “clear vision” of who their product actually serves as well as how their product is actually used.  There were two other important questions in my survey, which asked if the respondent had:

1. A solid understanding of their product’s special niche in the market
2. A clear vision of how their product will mature over time.

It turns out that a slight majority of my techie friends believe they know their product’s special niche in the market while only a very small minority believe they have a clear vision of how their product will mature over time.

Ok, I get the product niche result. I agree that most developers know at least a part of their product niche.  Approximately 60% of the techies said they know their product’s niche.  My personal bias – based on 20 years of development experience –  is that they probably know about 60% of their niche.  For example, when I worked at Cisco Systems, I was told that our niche was the fact that our software ran on Cisco routers, the best name in internet infrastructure.  Perhaps that was all there was to know?  But I suspect there was more, or should have been more. 

Still, it’s the responses to the roadmap question that floored me.  I spent some time puzzling it out.  I couldn’t understand why techies would say they don’t have a good vision of how the product matures over time. After all, the techies are the people who see the requirements, give estimates on implementation, make the design decisions and actually do the coding. As the people who implement the product, there are only a few people in a company more powerful at affecting the product than the developers.  How can they not have a vision of how their product will mature?

Of course, being a developer can be incredibly frustrating at times. Feature requirements grow and shrink, and sometimes seem to be made-up. Schedules and priorities change on a daily.  Managers and co-workers (and their opinions, biases and methods) come and go, sometimes with great force. A developer can feel quite powerless in that surf.  However, a truth behind that dynamic is that the developer is more plugged into the priorities of their company and the future of their product than almost anyone else.  The developer may know nothing about the next big sales deal, but if he doesn’t know how his product will mature, who does?

This thought probably leads to some reason for the survey results: Even though developers have a better sense than most of how their product will mature over time, they obviously don’t actually know how it will mature. They know that whatever features they start to implement will change.  They know that even seemingly small requests from the company often have significant implementation ramifications, which then leads to the company making different feature requests.  Furthermore, my survey asked if they had a “clear vision” for the future of the product, not just some vision.  With all the shifting demands that occur during any development project, my techie friends are completely reasonable to say they are unclear about the future direction of their product.

Still, the survey results are surprising.  Why?  Because it’s these same techies who aren’t clear about their product roadmap who are very clear about their product’s users and its actual use. So, either my techie friends spend a lot more time with the users and at customer sites than I did as a programmer and project manager, or they’re overlooking the complexity of real users and real environments. 

Does the shoe fit?

Do Techies Really Know How Their Product Is Used?

Last week, I learned that the vast majority of my techie friends (development managers and developers) believe they know how their product is actually used in the real world and who their product actually serves based on their responses to a short survey.

These results shocked me. 

In my experience, most developers work in fields where our primary value is:

• Our ability to program in the right language,
• Our skills at making good design and architectural decisions, and
• (For long time employees) the deep technical knowledge we have of our product and codebase. 

I have met few programmers who have a deep, credible image of how their product is used or who it actually serves. (Except for the case where the builder is also a user, such as a cellular phone interface programmer at Nokia.)  Even programmers who are subject matter experts in their product’s field often have no more understanding of their product’s users and environment than a professional volleyball player has of my inability to spike a volleyball and what life looks like as a woman not quite 5 feet tall.

To me, image is the key word.  In my experience as a developer, we each imagine a user – or two or three – who help us make decisions when designing and implementing our product.  I believe we ask ourselves, “What does my image need here?”  If the decision requires something we had never considered before, we make our best guess, grow our image accordingly and continue implementing our product.  (Of course, every developer on the project will have a different internal image of the user, leading to those too familiar discussions about what features are necessary and how they should be implemented.)

As far as understanding how our products actually fit into the real world, I have to admit that I rarely gave that a thought when I was a techie.  Sure, I knew my DHCP server had to hand out valid IP addresses, my router balancer had to accurately load balance the demand on the routers, my students had to be able respond to the test questions and be prevented from cheating, my manufacturers able to manufacture …. But I had little idea or interest in how my products fit into the demands and goals of the customers’ everyday life.

So, for all you techies out there: Do you really know how your product is used in the real world? Do you really know who your product serves?  And for your product managers: Do you know these answers?  Do you think your techies do?

I'd love to hear from you on this.  I’m quite curious.

If Personas Are So Great, Why Haven’t I Heard Of Them?

As I talk with more and more people about personas, I find very few who have heard of them. I find this interesting as my social and business spheres are mostly populated with people who build, market or sell software for a living. Of the people I have recently spoken with, some product managers, a few marketing people, and none of the developers (except those I’ve provided personas to) are familiar with the concept of personas. At a recent BPMA meeting, I quickly asked the group how many of them were familiar with personas. Roughly ¼ of the attendees raised their hands. As a persona evangelist I clearly have my work cut out for me.

Here are my top 5 reasons why everyone isn’t yet using personas:

    #5. ‘The Inmates Are Running the Asylum’ was published in 1998, and good news travels slowly.

    #4. Some companies have a respected internal person who advises the developers and marketers on the user and buyer needs, skills and goals.

     This is akin to the ‘feed a fish vs. learn to fish’ metaphor, because while not a substitute for personas, a strong user and buyer advocate will eliminate the screaming need for personas within the development organization.

    #3. You’ve seen cardboard personas and decided personas are just more paperwork.

     IMHO, this is a mistake similar to deciding that OO programming wasn’t useful just because you started working with early version of the MFC.

   #2. The companies using personas realize they have a competitive advantage, and are keeping quiet.

     Not to make you paranoid, but might this include one of your competitors? Have they just put out a great new release? Are they about to?

   #1. Programmers just want to program.

     Personas are the cure for analysis paralysis! If you want to do more programming and less of everything that isn’t programming, tell your management you want a set of rock-solid personas.

While there are probably more reasons than this list of why you may not have heard of or not be using personas, I’m confident it’s just a matter of time before all good developers realize they need a set of personas to go with their requirements.

What Users and Buyers Really Want

The May 28^th issue of the New Yorker included a “Financial Page” article by James Surowieki, called “Feature Presentation” which I found interesting. In the article, Mr. Surowieki describes the “peculiar problem” companies experience when attempting to meet the demands of buyers, who want every possible bell and whistle included in technology products, and the demands of users who want simple, intuitive products that meet their needs. He notes that users have poor skills at evaluating their skills and so purchase products too complicated for their use. Mr. Surowieki contends that since feature creep is the result of giving the user as buyer what he asked for, there is no easy solution.

I counter that there is an easy solution. While I am a tremendous user advocate, I am not a fan of building necessarily what the user explicitly asks for. Rather, I’m a fan of building what the user and the buyer actually want. To build a product people actually want requires us – the designers, the developers and the product managers – to see a much bigger picture than just the product’s feature set. To build a product people actually want requires us to:

• Deeply understand and empathize with the user’s and the buyer’s skills, goals, hidden desires, biases and environment
• Be aware of our product’s roadmap and our company’s plans for the future
• Be cognizant of our product’s special niche in the market

And to use this knowledge in our product planning, product development and product marketing.

Mr. Surowieki writes “In theory, the best strategy is to make complex features simple, packaging all the power and the options people think they want into a design that they’ll find easy to use.” In fact, he and I would agree if I could just rephrase that sentence a bit to “The best strategy is to implement features that are appropriately complex to meet the skills of the user they target, packaging all the power and options people actually want into a design that they’ll find appropriate for their use.”

I think I’ll write to Mr. Surowieki about personas.

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 (and I) 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.

The good news is that 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?

Not familiar with personas? You are hardly alone. 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.

Why A Blog On Personas?

Several years ago, I received some fantastic Product Management training from Steve Johnson of Pragmatic Marketing. In addition to Steve’s insightful personal anecdotes about working in and guiding product development and marketing, the training included the advice that “Personas” – or carefully chosen example users – should be used to guide the product requirements, development and marketing.

Something about the concept of personas resonated with me, so I did a good bit of research on personas, including reading “The Inmates are Running the Asylum” a very persuasive book by Alan Cooper in which he first introduces the concept of personas for product development. After several months of research, my sense that personas could be a very valuable tool for influencing the overall goodness of the product under development was stronger than when I’d started.

Let me interrupt this recollection to tell you something about myself. I’ve been in software design and development for 20 years. Over the course of my career, I have sometimes found myself in the frustrating situation of knowing the product I was working on was being mis-built. That is, that the developers and management were making technical and implementation decisions that simply wouldn’t work for the intended user base. Maybe it was my years in technical support, maybe the fact that I am the child of business owners – I don’t know, but somehow, on these occasions I knew that our values and judgments were off. Sometimes I knew better choices. More often I just knew that we didn’t know enough.

This mis-building of product is never intentional, as everyone always wants their product to succeed. Just getting a project approved takes a tremendous amount of work. First, there is the market research, executive presentations, evangelizing, and board meetings. Then there is the research and writing of lengthy requirements, followed by the writing and debating of lengthy specification documents. Until, finally, we get the chance to actually build the product. In the end, it is the developers and their management who really decide what gets built, how and when. Yet, we developers are usually the ones with the least exposure to the user and the market.

Companies try various means to expose us developers to the needs of the user including corporate trips to user sites, user visits to headquarters, highly detailed requirements, lengthy specifications, use-cases, scenarios, etc. However, none of these accomplish what the persona promises to do.

The persona promises us:

• A realistic description of “the right” user and his needs, skills and desires.
• An awareness of the environment in which our product will be used
• The ability to empathize with the user

Thus guiding a team of developers to make good, consistent, long term and common decisions while implementing the product.

I finally got the opportunity to give personas a try. You can read about my experience in detail in the August '07 issue of the Pragmatic Marketer.  Until that’s available, I’ll summarize the experience here by saying: personas brought a sea change at every level. Product decision making improved immediately throughout the organization.

In particular:

• Developers felt empowered.
• Product Management and Development were finally on the same page.
• Product Managers were required to do far less internal evangelizing.
• Developers documented less and coded more.
• First-pass implementations met the users’ needs while matching their skills.
• Marketing improved their customer and prospect communications

It’s now been a few years since I was first introduced to the concept of personas and I remain very impressed with the immediate and long-term impact of good personas.

Since the concept of personas, their value and their impact is not yet widely established, I have started this blog to help get the word out.