Home > Personas > Persona-bly Speaking

Persona-bly Speaking

Recently, there has been much tweetage amongst the #prodmgmt community in the Twitterverse on the subject of personas.

It all started innocently enough when @bstnmelody tweeted “Need help from #prodmgmt cmmty. Translating customer interviews => personas. Any1 have framework they like besides Pragmatic?”  As when any of us in the community ask a question, there are many to step forward and offer advice and point us in the direction of reference materials (and that’s what makes the #prodmgmt community so great).  However, when @ms5 responsed with the  “I have an easy “framework”, if I can call it that! Just don’t do personas – they’re mostly a waste of time…” , a firestorm quickly followed.

Many in the #prodmgmt community, myself included, called @ms5 out for his bold statement that personas are a waste time.  We dove straight in and defended the honour of persona’s – reminding all of their value in software development, both for buyers and for users.

The risk of any electronic communication, especially when limited to 140 characters like we are in Twitter, is that sometimes what you intended to say is misinterpreted and that may be the case here.  As Michael was forced to defend himself against a claim that by not writing persona’s that he didn’t care about customer needs or that if you don’t do persona’s you cannot be successful.

However, what he seemed to really mean was that writing persona’s was a waste of time because people didn’t use them correctly and as such were not worth the time and effort spent to create them. (Michael, if I misinterpreted your point please correct me)

To me, this seems like the wrong approach.  Instead of tackling the problem head-on and figuring out where they went wrong, it seems like they took a defeatist stance – “if we can’t do it right, we won’t do it at all”.

I’m not going to go into a lot of details on why personas are valuable.  There have already been a number of other blog postings on the subject.  You can check out @jidoctor’s blog postings here and here for some insightful comments.

So, what are the problems with some personas and why might be creating them a waste of time?

  • The persona contains too much irrelevant details – the best personas I’ve seen get straight to the point – they describe what the person needs to do, how they do it today, how they get their information and some other characteristics that might drive how they accept and use technology.  Whatever it is that you need to make the right decisions for your product.  Don’t waste time defining a back-story for the person, what they like to do on weekends, what they had for lunch etc.  unless it really will help.  However, on the flip side, making them too generic won’t be useful either
  • Buyer personas vs. user personas – I’ve seen people try and use one set of persona’s to do both.  Unless your software is going to be used by the person who is signing the contract and paying the money, you need to understand the unique needs of both.  Buyer personas describe who the buyer is, what their challenges are, how they make decisions, how they buy software etc.  User personas describe the person who will be at the other end of the keyboard.
  • Writing one persona to describe all your users – the product that I am Product Manager for has many different users.  Each uses the system for different purposes.  Lumping them all together as one persona would be a waste of my time and would largely be unusable.
  • Writing personas without really understanding your user – are you writing based on the marketing materials and how people think the software will be used or have you been in front of your perspective and current users to truly understand their needs and challenges.  Writing from afar could be a waste of time
  • Writing them but not using them.  As @jidoctor blogged – “you put them on the shelf”.  Of course, putting in any amount of time and energy on something that is not used is a waste of time.

How are we using them?

  • Defining and describing the various users of our product – making sure that when we add or enhance functionality that we ensure that the solution addresses how they would use the software and what they need to do in way that makes sense to them.  Knowing our user has eliminated many hours of “debate”, allows development to focus and results in software that is well received by the user.
  • Understanding our buyers – what their pains are, how they buy software etc.  This has allowed Marketing and Sales to focus their efforts, concentrate on messages and collateral that is relevant and well understood.
  • To refine our technical documentation – how does the user of each guide want to reference the documentation, how do they learn, what do they need – do they want specific step by step instruction or instruction in context of what they need to achieve.  The documentation becomes worth the “paper it is printed on” (we actually don’t provide hardcopy, but you get the point)

Now, I’m not saying that writing personas is the only way to communicate “customer” needs, but when done correctly and used they can be indispensable.  I would be interested in hearing more from those who have not had the same experience.

Advertisements
Categories: Personas
  1. davidwlocke
    September 25, 2009 at 11:16 am

    I’m I communicating the customer’s needs or the user’s needs. Only the user’s needs should be communicated. Customer’s needs are satisfied subsequent to the satisfaction of user’s needs.

    Current practices embed hidden costs in the customer’s business by failing, in fact, to deliver functionality that suits each user, as a consequence of delivering functionality that suits an average, at best, of all users.

    Software is a media. A media consists of a carrier and the carried.

    The carriers in software are the programming language, the code frameworks, the database, the networking protocols, patterns, and refactoring. This is where “How” lives. Programmers spend most of their time here. Programmers abstract away from the requirements. The decision tree traversed by the development process diverges widely and finally converges to the user interface.

    The carried is the content, the conceptual model of the users. The carried is the what. The what isn’t really functionality. But, the meaning that drives practice in the performance of work. Requirements doesn’t capture meaning. So as a replacement for requirements, personas miss the mark as well.

    Agile may have eliminated the obviousness of requirements volatility, but that volatility remains embedded in our processes. We still push costs into the customer’s organization, so we can remain efficient, so we can deliver average functionality, so we can capture suboptimal revenues by relying on market segmentation.

    Agile and personas work fine when coding internal applications, but what works there doesn’t work in software vendors. Yes, you can get code out the door, but its all average and followed fast, so the software vendor makes less money.

    The question around whether programmer use personas or not needs to be studied. If programmers don’t use them, who does? Does marketing or user support do things based on personas? You’ll need video, otherwise, asking questions will just get you the answers you want. In the end, you may have to train programmers, but what software vendor will do that.

    Personas do get used in e-commerce sites staffed by designers doing web development. This is just a sign of the divide between the MFAs and the MS CS populations.

    It’s been kind of fun to watch the MFAs work themselves into software engineering even as the CS types run away from it.

    Beyond whether programmers use personas, the people who write them gain from their efforts to think about what they are delivering.

  2. September 25, 2009 at 11:38 am

    I’m reminded of a customer I worked with previously – one of the top 5 banks – where the product manager told me: “We don’t do personas because our target market is everyone.”

    “Everyone?” I asked.

    “Yes,” she said smugly, “our customers come from EVERY demographic.”

    “But some of your customers are more profitable than others, right? More likely to engage in activities like bill pay that make them more profitable to you?”

    “Of course,” she said, “customers who use online bill pay are $X more profitable per year.”

    “And there are certain demographics who are more likely to try online bill pay, right?”

    “Probably,” she said, “but we don’t really know who they are.”

    A better argument for creating personas, I cannot muster. 🙂

  1. October 3, 2009 at 1:53 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: