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.

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.

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.

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.

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.