Product Personas

Is Your User Dangerously Elastic?

We all imagine a user when we build our software. Have you ever committed your imagined user to paper (or bytes)?  If you haven’t, try it now. 

.... <thinking>
.... <writing>

Were you able to do it?  Congratulations. Many times, I can’t even get an initial description to paper.

Now, how does he look?  Did you describe:

• The reasons he is using your product or feature?
• His work or play environment while using your product or feature?
• The skills he has with and brings to your product or feature?

Is your user robust, realistic and consistent?  If so, you obviously know a great deal about your user base, so read no further.  If not, you’ve likely got one of two problems:

1. You don’t (yet) know your users, and are guesstimating, or
2. You do know your users, but having segmented them according to need and skill.  This is called an “elastic” persona, where the user is stretched to meet qualities that are simultaneously impossible. 

Imaging building features for advanced users with an interface for the relative novice; expending a tremendous effort to make your product localizable when the users (foreign and domestic) will only ever use the English; or spending too long building the primary user’s interface when that user’s time is cheap (and she has no influence over the buying decision).  These are 3 elastic user situations I’ve encountered just this year.  They were all a waste of effort, time and money.

If you’re guesstimating your users, I recommend you read this posting on improving your user image or persona.  If you have elastic personas, you may simply need to carefully divide the users according to their needs and skills.

Let me know if you have any questions.

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. 

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

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.

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.

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