Nov 13

Deepen Your Expertise and Get More Innovative: Five Links Worth Your Time

This week and last have been hard on the old cognitive capacity, and the topics I’m working on for the blog need a lot more cognitive work than I’ve had available.

Or is it just that I’ve spent too much time reading really interesting articles on the Internet? Here are some good ones I’ve run across in the last week that I wanted to share, in lieu of a real post. Each of these posts is worth the time spent to read (or watch) it.

  • First, Bruce McCarthy (@d8a_driven) turned me on to Jason Brett’s excellent “60-second Business Case heuristic for creating a “strategic score” for a set of features. I described a similar scoring method in How To Prioritize. Jason and Bruce discuss it in this post on Bruce’s blog
  • @SeriousPony mentioned this great seminal Alan Kay talk as a first step for understanding how to do user experience and user interface better. I loved the talk – it’s full of throwaway lines that become touchstone aphorisms for us latter-day practitioners, such as “Find a context that will do most of your thinking for you,” (about 25 minutes in).
  • One of my recent hobby horses, as you know if you’ve read the blog, is that product management – creating new products – is not a straightforward application of best practices or techniques. Coming up with new products and new features is complex, full of emergent knowledge. Therefore, I was pleased to see this article on Insight-Driven Innovation in the MIT Tech Review blog. Simply having and understanding or analyzing a lot of data does not get you disruptive innovation. You need to have a moment – or multiple moments – of insight that are patently NOT data-driven. “Disruptive innovations need divergent thinking combined with instinct and gut.”
  • From Sarah Davanzo, “culture cartographer,” comes “The Trend of E-shaped People,”  extending the concept of T-shaped people – who have a combination of broad but relatively shallow knowledge across a range of topics (“Experience”), and deep knowledge on one or more particular topics (“Expertise”) – to include two more items – a tendency to “Explore” and an ability to “Execute.” The result is not only four “E’s”, but you can also use an “E-shaped” graphic to illustrate it. 
  • Finally, my current favorite moment each week is when I receive @katemats’ and @katestull’s Technology Leadership News (TLN) in my Inbox. Every week there’s at least one article that I take immediate action on. One of my favorites was “Nine Creativity-Sparking Tips” where I learned “your obvious is your art.” It kind of changed my life to get that understanding. (And I suspect the E-shaped people article was already mentioned in TLN at some point.) I’ve even configured RescueTime so that reading TLN counts as Highly Productive time, since I learn something I put into practice almost every week..

Oct 13

Is Your Product Like A Well-Run Restaurant, Or A Dirty Dive?

A Good Product Satisfies And Delights Like A Meal At a Great Restaurant

You can use the restaurant metaphor endlessly when talking about products. A well-run restaurant has many of the qualities that we want in an elegant, productive application. The front of the house is clean, it’s satisfying, what you get is closely related to what it says on the menu, it conforms to reasonable expectations and conventions, such as appetizers come first, then entrees, then desserts. And a good waiter is a wonderful analog for the user’s experience.

Oven and Stovetop at Broder’s, CC 2.0 licensed by Accidental Hedonist

In a good restaurant the back of the house is a well-running machine that you don’t have to know much, about staffed by people who are experts at doing what you want, in hygienic conditions and with hygienic practices, where the food is fresh and anything that jeopardizes those things is dealt with immediately.

A Bad Product Is Like Eating At A Dirty Dive

But the user experience of a lot of products is more like a restaurant where the menu is not organized into appetizers, entrees, and desserts, and where if you ask the waiter “what’s good,” he says “didn’t you read the descriptions? How do I know what you’d like?” and who then gives you a separate menu that has meaningless descriptions of each dish that only says what the ingredient list is (but not all of it), and doesn’t say anything about how the food is prepared.

In fact, it can be a lot worse than this. There are plenty of products out there that are like a restaurant whose walk-in fridge is broken, the food is spoiling, and only two of the burners on the big stove are working. Not only does the food (desired results) come out slowly, but it might be spoiled. This is especially bad if all the owner wants is new dishes on the menu, plus a better font.

If your restaurant was in that kind of shape, you’d go out of business fast unless you moved quickly to get those behind-the-scenes problems fixed. And no menu change would help, especially not a font change.

What kind of “restaurant” are you running? Is the kitchen in good shape? Are you putting out fresh, unspoiled dishes? Can the cooks keep up with demand (no broken stoves)? Does the food that’s coming out of the kitchen line up with what it says on the menu?

Oct 13

The Secret To Successful Products That Users Love From Day One

As a software product manager you have to raise your expectations on what the application will do for the user.

A Twitter Challenge Is Laid Down

Yesterday, @seriouspony tweeted:

A conversation ensued:

And I invoked the God of product design:

Visual Voicemail Is A Metaphor For No Habits

Before the iPhone, voicemail was accessed by making a call, listening to a robotic voice and navigating your messages using the number keys. This required knowledge, and incentives and habits to do well.

Jobs said (in effect) “name + tap is our interface.” No learning, knowledge, or habit required. And he committed to a lot of work on the part of the Visual voicemail app to hide all that stuff on the back end so the user didn’t have to know any of it anymore.

And interestingly, partly as result of this design approach, a habit was formed – the habit of buying an iPhone and checking it all the time.

Applications Must Embed Deep Knowledge To Be Successful

The most popular part of this conversation was this thought, which you can detect in many applications that win their space:

It seemed to strike a nerve with product managers, and was favorited several times. In the Twitter conversation I mentioned Instagram, which automatically takes good (enough) pictures.

To use one of @seriouspony’s key phrases, these applications with embedded knowledge help users kick ass. Want to take some good pictures? You can take photography classes and practice a lot, OR you can use Instagram which will instantly make even non-perfect images look a lot better. No habits needed, no knowledge needed, no incentives needed.

This also echoes comments Evan Williams made recently at the XOXO conference:

“Take a human desire, preferably one that has been around for a really long time … Identify that desire and use modern technology to take out steps.”

People already wanted to share images of their lives, Instagram just made it faster and better.

It’s Not Just iPhones – Enterprise Applications Win With Knowledge

It’s not just consumer applications that do this. My old product AppManager (from NetIQ), dominated its space because it came with built-in knowledge – simple, default monitoring scripts – while its competitors typically made the customer write and configure their own scripts. And even though the users of the application for the most part could have come up with the settings themselves, the fact that the application already had a good set of defaults meant that they didn’t have to do any thinking and could rely on us to have done that thinking. That meant they could use that cognitive capacity for other, more interesting or valuable things. That meant our customers could kick more ass. And that resulted in us winning that market handily.

Don’t Be Stupid; Take The Load Off

The important thing from the product management perspective is that you have to raise your expectations on what the application is going to do for the user. To get more knowledge into the product so it’s not stupid and takes load off the user, you can’t do the simplest possible thing – you have to do the hard(er) thing.

May 13

People Don’t Remember Features

Peter Abilla had a great quote in his post On Customer Obsession:

People remember experiences. They don’t remember attributes or benefits or features.

The quote is from A.G. Lafley, CEO of Procter and Gamble, in the January 28, 2005 Business Week.

It’s something I struggle with often as a product manager. Like most product managers, I’m technical, so I love all the new features and gewgaws. But as I look back at my previous releases and at customer response to them (and my own response – at my previous job I used my own product on a daily basis), I find it hard to remember which features were new and which were always there. My experience today with the product is what matters – it’s a great result when the improvement of experience aligns with the new features.

I’m happy to say that the new version of my product is delivering some experiences that my customers are getting value from. But I’ve certainly shipped features in the past that excited me as a technologist, and that were expensive and fancy and worked well, but that didn’t improve the customer experience.

Sep 12

The “Drive” To Gamification: Motivation 3.0 and Game Mechanics

Dan Pink's Excellent Book "Drive"

Dan Pink's Excellent Book "Drive"

Gamification, especially as it applies to enterprise applications, is all about engagement, and quality, and helping people achieve their goals. Or, to put it another way, it’s about motivation. There’s another approach to thinking about motivation, especially of knowledge workers (i.e., those who work with enterprise applications), and that’s as exemplified in Daniel Pink‘s awesome book Drive: The Surprising Truth About What Motivates Us. For the purposes of this discussion, we can summarize Pink’s main point briefly as follows:

We are in the age of “Motivation 3.0,” and motivation primarily is driven by three key dimensions – mastery, autonomy, and purpose. That is, if you want people to be motivated to do their work, they have to have or be working toward a sense of mastery. They have to feel they have some amount of control (or autonomy) over what they do. And the work they do has to be aligned with a higher purpose, it can’t just be “because.”

How does this idea of Motivation 3.0 apply to or intersect with gamification? Gamification is the solution to a lot of problems that especially enterprise software faces. In particular, gamification is intimately related to surfacing the components of Motivation 3.0 – mastery, autonomy, and purpose.

  • Mastery: Games are the best examples we have of reporting on a person’s mastery of something. Nothing else is as good. PhD dissertations are not that good, as we all know. High stakes testing is terrible. And so on. Games have this all over the place, with their points, levels, leaderboards, badges, etc.
  • Autonomy: One of the key components of autonomy is the “ability to get into a flow state.” And games, again, are among the best examples of this, and they certainly are the example of getting people into flow state more easily than any other activity. Even musicians have a harder time getting into flow than gamers do. Millions of gamers every day have to be dragged from their game consoles or computers after hours of playing because of the appeal of the flow that’s generated.
  • Purpose: One hopes in general that most peoples’ jobs provide them with a certain modicum of purpose, and that’s a fundamental assumption I make about gamification of enterprise apps – we’re not trying to solve the “purpose” part of the equation. But the work itself typically doesn’t help a person understand if what they’re doing is helping drive toward achieving the purpose. So, there’s a high level purpose, and we often have that in our job. But our day to day work may or may not be helping us achieve it. Games, again, are amongst the best tools we have for understanding if we are achieving our purposes. In games, of course, the purpose is much less compelling than a real life purpose (“Save The Princess!”) but because the linkage to making progress on the purpose is so strong, it’s enough to keep people engaged. Just think of the power we could have if the day to day, hour to hour work of a person could be seen, by the person, and in a legitimate, non-condescending way, to be aligned with and furthering the high level purpose. That could be ultimately compelling.

So, that’s my take on how the ideas in Drive align with gamification. What do you think about this? I’d love to start a conversation about this below in the comments section!

Aug 12

We Need Some Stinkin’ Badges – Gamifying Enterprise Applications (Part 4)

Arrows ("points" - get it?) (Image by Travis C, CC 2.0 licensed

In previous posts in this series I started by asking “what is the goal of gamifying enterprise apps?” Is it to make them more fun, is it to make them more engaging? The answer is “neither” – the goal is to enable the users to be more effective or better at their jobs. Making applications more fun and engaging is a plus but it should be a side effect of enabling users to be more effective. The fundamental driver behind this concept is that the users of enterprise applications are already motivated to do a good job – that’s why they have the job in the first place. And the problem of enterprise applications isn’t that they’re not engaging enough or fun (although those are problems). The problem is that the applications typically make it hard to get the job done correctly or right or easily. This isn’t good for the users or for management.

I then laid out an example of an application that I’m very familiar with, Accept360, that will be a good testbed for some ideas about gamifying enterprise applications. And then in my previous post on the subject, I listed out Gabe Zicherman’s (@gzicherm on Twitter) six rules for gamification, and started to work through how those rules applied to the example application.

Now we’re on to the next step: to start applying some game mechanics to our example app. Again, not to make the application more fun or more engaging, although those are desired side effects, but to make the application support the goals of the users to get the job done well in a more effective way.

Points and Points and Points, Oh My!

What are some approaches that we can take as a first step to making this application better at helping people get their jobs? As Mario Herger has said, “Even the s***ty stuff leads to double digit changes [in engagement].” And even though engagement is not the goal, it is a good tactic that will have impact on improving the quality of work that’s done with the application. So let’s start with a very simple addition, in fact, what’s usually the first step. We’re going to put a point system into the application. This is also the approach that Gabe Z uses in his book, Gamification by Design – he starts with adding a points system to his example.

What shall we reward points for? There are a lot of activities of people do in the application that are either considered good in general, or are indicators that the user is doing something useful. These are activities like:

  • Logging in to the application
  • Creating a new element within the application
  • Editing an element with an application
  • Participating in a discussion thread

The primary benefit of points is to encourage individuals to use the application, and the use of different point values for different activities influences their choices as to where they spend their time.

Encouraging Collaboration

But in addition to encouraging use, I have two other ultimate goals in gamifying Accept360: 1) encouraging and promoting collaboration between users and 2) promoting quality work, by pointing out and featuring excellent examples of the work products of the application – which means requirements, product plans, value propositions, and all the other types of elements that can be created within the application.

We’ll combine points with the mechanism of badges as the approach to achieving those two goals. To encourage collaboration, I can reward users who initiate collaboration, using a set of “collaborator” badges. And I can reward users who provide expertise with a set of “expert” badges. I want to encourage users who need help to ask for it, and more importantly, to know who to ask.

So for each of the activities, we’ll specify one or more badge series to which the activity contributes. For example, if you participate in a conversation about a feature, you are working on your Collaborator badge. If you create a new requirement, you are working on your Author badge. If someone votes up something you wrote, you’ll be working on a Expert badge. If someone marks one of your items as an example, you’re working on a higher level Expert badge (perhaps the “Master” badge).

This also requires adding a few more activities that are directly related to collaboration and becoming an expert:

  • Voting up an item (gives points to both the voter and the author of the item)
  • Nominating an item as an exemplar

The Story So Far

So, summarizing what we have so far. We have a points system in which the following activities are rewarded:

  • Logging in to the application
  • Creating a new element within the application
  • Editing an element with an application
  • Participating in a discussion thread
  • Voting up an item (gives points to both the voter and the author of the item)
  • Nominating an item as an exemplar

And then we also have a set of badges or recognitions that you work toward as you do the desired activities, including the following series:

  • Collaborator
  • Author
  • Expert/Master
  • Resource

That’s all we have space for in this post. There’s obviously one key piece of data missing so far, which is how many points do each of these activities get you? And we also need to explore how you build up enough points in the badge categories to get the badges. I’ll cover those in the next post in detail.

After that, we’ll need to come up with a few UI approaches for displaying all this new data – the points and badges, as well as leaderboards, at minimum.  Then we’ll playtest these settings to see if they have the desired impact. We’ll take up that discussion in future posts, and start talking about more advanced ways in which to increase engagement, which are more than just “slapping points” onto existing activities.

For one thing, we’re going to talk about turning certain activities into actual mini-games or puzzles. For example, one of the things that people doing product management should do is create what’s called a “value proposition” about their product or release. But this often doesn’t happen, and this is because value propositions are somewhat difficult to write, even though there is a canonical form, and they are extremely valuable when creating marketing materials around the product, or indeed, in deciding what features to add to the product and which ones to defer or drop.

So, a mini-game around the creation of value propositions will give users a fun and engaging way to do a task that they normally prefer to skip, despite its value. And by gamifying that task, users may even end up with higher quality results than they would have without gamified tool support.

As always, please let me know what you think in the comments, and feel free to sign up for my email list so you can get new blog posts in your email.

Jun 12

Gamifying Enterprise Apps – Fun or Engaging? (Part 1)

Yesterday I read The Future of Enterprise Software Will be Fun and Productive by Michael Wu, Principal Scientist at Lithium and a gamification guru. He focused on “adoption” as the key metric to improve in his example of CRM, his example of an enterprise app (understandably so, since Lithium’s primary product is a social CRM application). And the key question he asked was how can we use game mechanics to make social CRM more fun, and therefore achieve better adoption?

FUN Button

Just push the "Fun" button for complete adoption! (Image by Hodgers, CC BY-SA 2.0 licensed)

If gamification has so many benefits, why wasn’t enterprise software gamified? I hate to speculate, but I suspect that one of the reasons is that fun was never a requirement for enterprise software. Early software architects simply did not understand that fun and adoption go hand in hand. If you make it fun, people will use it. If you truly believe enterprise software can boost productivity (if used properly), then fun becomes a requirement for productivity, since adoption is clearly a prerequisite for realizing the productivity gain from using the software.

Fun – or Engaging?

Now, I have a quibble with Wu’s approach. In particular, I disagree that enterprise software has to be fun to boost productivity (or adoption). I prefer to focus on the sense of engagement, for several reasons. First, lots of things we like to do are not fun, but they are engaging. For example, cooking. Making art. And exercising. These are fun (sometimes) as a side effect, but what keeps you going in any of these activities, and keeps you coming back and improving your skills (or fitness), is not fun, per se.

Enterprise Applications Start With a Lot of Advantages

Getting back to enterprise software, I work from the fundamental assumption that the people working with my application want to do a good job, and they are willing to put up with some pain and inconvenience to do so – they will come to work, they will work with the prescribed software, they will go their meetings, they will collaborate with people whom they might not want to socialize with in the best of all possible worlds.

So, people are already giving us providers of enterprise software a giant leg-up on getting them engaged – they’ve committed to be there, they’re probably interested in the subject (that’s part of how they got the job) which provides intrinsic motivation, and they have extrinsic motivation to do their job (that is, their paycheck).

This is great news is the makers of enterprise applications, especially those for knowledge workers – we already start from a high position in terms of motivation for the users – they want to do a good job and they want to help their company and their customers be successful. (That’s “mastery” and “purpose,” from Dan Pink’s Drive, if you’re keeping score.)

So Where’s The Problem?

The first thing we can do with our enterprise apps is get out of the way of this intrinsic (and extrinsic) motivation to do a good job. If the app makes it harder to do a good job, for whatever reason, it’s going to cause problems not only for the user, but for the business as well.

What we find in the real world, though, is that many enterprise applications actively work against this intrinsic motivation of its users. Here are a few of the ways this happens:

  • A choppy experience – where you have to navigate hither and yon throughout the application in order to complete a process
  • Lack of flow – this is related to the previous example, but is specifically about the fact that most enterprise software is not designed to help its users achieve a state of flow, even for a single process.
  • Rigidity that doesn’t match the real process – this is the situation where the system makes you enter information before you know it, or doesn’t let you enter information that you do know because you’re not in the right phase or the right screen
  • A repeated high barrier to success, especially for processes that are important, but that the user doesn’t do very often, requiring the user to re-learn that part of the application over and over again every two weeks or every quarter
  • A complete lack of feedback to the user on whether he or she is doing a good job
  • No ability for a user to see what a good job looks like
  • No ability for a user to get advice or guidance from another, more expert user
  • No ability for a user to be recognized as an expert

Some of these obstacles can be solved just with “good design,” while others are very amenable to game mechanics and what I call socialification – a set of mechanics related to gamification but focused on social aspects such as presence, guru ratings, and feedback.

Coming Up Next – A Worked Example

In the next installments of this long article, we’ll describe an enterprise app that makes a perfect target for gamification, and then we’ll start from Gabe Zichermann’s six rules of gamification and take a stab at defining a gamified version of that app.

In the comments please let me know what you think of my characterization of the challenges of making enterprise applications engaging, and whether you think I’m right or wrong about “fun.”