Gamification Summit 2012 San Francisco – Session Highlights

There were almost 20 sessions today at the Gamification summit – and the quality ranged from OK to excellent. In my opinion, the most interesting sessions were, in chronological order:

  • “The Future of Gamification is Emotion,” by Nicole Lazzaro, President of  XEO Design. I’d seen some of this material before on her website and in presentations on the web, but it was great to hear her in person, and to see again her very straightforward “Four Keys To Fun” model. It seems to me that if you are thinking about gamification (or making games) you need to learn these four keys and apply the concepts.
  • “Come for the Game, Stay for the Community: Building and Sustaining Lasting Engagement Online,” by Dan Porter, CEO of OMGPOP. In a very funny and profane talk, Porter described a number of the gamification-related learning that arose during Draw Something’s rise. His points aligned very well with Nicole Lazzaro’s, and illustrated the importance of really paying a lot of attention to fun, and how your users can have fun. Of course, Draw Something *is* a game, not a gamified app, so it had *better* be fun!
  • “Monopoly Academy: Winning the “Game” of No Child Left Behind through Gamification and Monopoly, the World’s Most Famous Board Game,” by Tim Vandenberg, Teacher at Hesperia Unified School. Tim uses Monopoly as the primary teaching tool in his 7th grade math class, which has, since he started this pedagogy, not only crushed the state test results, but also generated some very highly skilled Monopoly players who are competitive with nationally ranked professionals.
  • “A Game Designer’s View of Gamification,” by Richard Bartle, Visiting Professor at the University of Essex. Bartle is the originator of the player type concept of Achiever, Explorer, Socializer, and Killer, as well as the co-creator (according to Wikipedia) of the original multi-user dungeon (MUD). His funny and erudite talk focused on different approaches to dividing people up into types, and how many of those approaches are not useful for gaming (because they don’t focus on the different ways people have fun). And he noted that his player type categorization is probably not the best one to be found. He used it because it worked for his purposes, not because it was the optimal one.


Gamification Summit 2012 San Francisco – Day 1

A few notes and observations about the first day of my first Gamification Summit 2012 in San Francisco. Overall, this was a great day – I met quite a few people, heard quite a few good presentations, and started to get a sense of what’s going on in the gamification world right now.

The conference opened with a short introduction by Dopamine‘s Gabe Zichermann, who laid out his three pet peeves about conferences and how he was going to address them.

  • His first pet peeve was long, boring sessions. These were addressed by having each session formatted basically like a TED talk, with an 18 minute presentation and some time afterwards for audience Q&A. This had pluses and minuses – perhaps I’ll get to those later.
  • His second issue was boring box lunches that most conferences have, and since this event is being held in San Francisco, he had some of SF’s famous food trucks in to cater lunch (I had a Cubano Sandwich from a sandwich truck whose name I unfortunately do not remember). For dessert we had cupcakes from another truck – lots of them!
  • Gabe’s final issue was a desire to fix the live-tweeting aspect of a conference, to make it smoother and more integrated with the program itself, and of course, given the topic, to gamify it. The answer to this was Memecube, a new application developed by Dopamine that integrated a conference schedule and a Twitter client, along with some game aspects. Unfortunately, the morning started out with Memecube not really working, so a lot of people ended up on regular Twitter. Happily, Memecube was working fairly well before lunch, and it was a good experience at that point.

Those were the logistical changes that Gabe made. In my next post I’ll talk about some of the content we learned about.

Gamification of Enterprise Applications – Applying Gabe Zichermann’s Six Rules of Gamification

In my first post in this series I discussed some of the issues that enterprise applications have from a usability and engagement standpoint, as well as the key fact that the users of these apps are inclined to be motivated, both intrinsically and extrinsically, to use them. In the second post, I described an enterprise product planning application – Accept360 – that will serve as a “testbed” for applying gamification ideas.

As a refresher, the key usability and engagement issues mentioned in the first post included:

  • A choppy experience
  • Lack of flow
  • Rigidity
  • Lack of feedback to the user on whether he or she is doing a good job
  • No ability for a user to get advice or guidance in-context from another, more expert user
  • No ability for a user to be recognized as an expert

Now, in this third post we’ll start from Gabe Zichermann’s six rules of gamification and see how we can address the usability and engagement issues in the context of our sample application.

Gabe laid out his six rules in a blog post in November 2011 as guidelines for people working on gamifying applications (not necessarily enterprise applications):

  1. Understand what constitutes a “win” for the organization/sponsor
  2. Unpack the player’s intrinsic motivation and progress to mastery
  3. Design for the emotional human, not the rational human.
  4. Develop scalable, meaningful intrinsic and extrinsic rewards
  5. Use one of the leading platform vendors to scale your project (don’t roll your own)
  6. Most interactions are boring: make everything a little more fun

These rules are great, and I don’t think you can go wrong with applying them to any application to get better results and better engagement. However, I think for the purpose of our enterprise application example, we can reformulate the first rule a little bit to talk about “the user,” rather than “the sponsor.” After all, as discussed in part 1, we’re talking about a tool that motivated professionals are using (and disliking, typically) to do a job they are motivated to do. So we don’t have to consider directly what the organization considers a win, we can consider what the user considers a win – by definition that’s something that furthers the interests of the organization.

Focusing initially on rule #1, “Understand what constitutes a win for the user,” we can think of a lot of opportunities for user “wins” in a typical enterprise app – things that users cannot accomplish easily, but which a game-inspired redesign can enable. At a high level, of course, simply getting through their job is the big “win” for our users. But making the process of getting through the job better will constitute the smaller wins we’re looking for:

  • Getting out of their way, that is, “don’t make me jump through hoops to do my job.” This relates to the issue I listed above of a “choppy” experience, where you have to navigate back and forth through lots of screens to achieve a goal
  • Let me know how I’m doing and where I am – how much work is left to accomplish this goal, am I close to “good enough?” How much more to get to “Exemplary?” This is like the progress bar in games like WoW that tell you how many more experience points (XPs) you need to get to the next level. And which is missing in pretty much every enterprise application.
  • Making it easier to complete a process that I do every now and then, but I have to relearn each time – this could involve a wizard-like interaction that provides context-specific guidance for completing the task effectively. Some applications have wizards, but they are often provided for the tasks that one does regularly, which means they are actually obstacles once the user learns the application and uses it regularly.
  • Guiding and structuring collaboration on a process that requires multiple people to complete. Of all the “win opportunities” this is the one that is probably best handled by existing enterprise applications. Because the workflow of information is often a critical business requirement, many enterprise applications incorporate a workflow approach.

Each of these activities constitutes a “win” for the user.

In the next post of the series we’ll continue our look at applying these rules to improve enterprise applications. In the meantime, let me know your thoughts, questions, and concerns so far in the comments.

Gamifying Enterprise Applications – An Example To Work From

As I wade into what can be abstract ideas about gamifying enterprise apps, I think it will help to make them more concrete with some examples from a product I’m intimately familiar with, Accept360. This is the product for which I’m the product manager, and believe me, as a daily user of my own product, over the years I’ve experienced all the issues I mentioned in last week’s post!

Accept360 Logo

Accept360 - For enterprise product planning

Accept360 is a product planning product that includes portfolio planning, requirements management, agile management, and other related capabilities. One of the fundamental operations in Accept360 is creation of a product requirement.

In our system product requirements are somewhat complex objects that not only contain a name and description, but can also have:

  • Multiple rich text sections
  • A complete implementation estimate (in terms of multiple tasks assigned to multiple resources)
  • Weighted relationships to market elements such as the customers who have requested or will benefit from the capability and the marketing themes that the capability supports
  • The suggestions and ideas we’ve collected from customers and the market that have driven the creation of the requirement in the first place
  • Child requirements that elaborate the main requirement
  • Any number of custom properties of various types

And just to make it trickier, a requirement can have any combination of these and many other pieces of data associated with it. Depending on a customer’s product planning process, they might want or require more or less data for each requirement type.

A requirement is thus a this fairly complex chunk of data. It typically takes a product manager multiple hours or days of work to get from initial draft to delivered capability, over the course of days or weeks or even months, and with multiple conversations and collaboration sessions with other product managers, development managers, and developers (and customers, marketers, executives, etc. – the list of collaborators can go on and on).

I’ll use these capabilities of Accept360 as a testbed for how gamification can be applied to an enterprise application. (I recognize that not every enterprise app can be as cool as Accept360, but it’s still a good example.) Because of its level of complexity – all of which is simply a reality of the product planning and delivery process – there are many opportunities for applying game design and game mechanics to make the use of Accept360 a better experience. Some of the most obvious examples might be:

  • Onboarding a user – When users start working with the product, you need to let them into the world of Accept360 gently, otherwise it’s too overwhelming
  • Providing step-by-step guidance to a user the first few times he or she does a new task
  • Providing guidance at any particular point in time about where or what the user should do next – for example, if they’ve written a requirement, perhaps it should be reviewed by a colleague
  • “Scoring” a requirement – letting the user see how their require stacks up against a “best practice” requirement, and then guiding them on how to improve theirs if it comes up short
  • Getting credit for a well-written requirement – ideally this would be done via review and voting by your colleagues who need to make use of the requirement (i.e., engineers or engineering managers)
  • Getting a rank or overall score that recognizes how good you are at writing requirements, or doing any of the other myriad tasks that make up the product planning process

I am using Accept360 as the example application for applying gamification because it’s the one I’m most familiar with, but I’d be interested to hear your thoughts about other enterprise apps that are ripe for game design and game mechanics. Let me know in the comments.


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

What Comes After Google Glass? (Part 2)

Yesterday I posted about how reading might change in a world where all our interactions are mediated by an augmented reality device like Google Glass. But I also mentioned some potential pitfalls, and in this post I’ll discuss them, as well as some ideas for avoiding them.

Reading “Out There”

I see a number of potential problems with reading using augmented reality. This is based on my own behavior while reading and while doing other activities and considering how they might be combined. In particular, in a world where your book is floating “out there” in front of you, you’re going to have problems with safety, with attention, and with distraction. If your reading device is the same thing you use to interact with the rest of the world, you’re going to be hard-pressed to just sit down, with nothing to do with your hands, and stare off into space (that is, into the book floating in front of you) and pay attention to the book. This is especially difficult if the rest of the world is kind of faintly visible through the book.

In fact, the great thing about a book and about the Kindle device is that when you’re using it, you can’t do anything else. It captures and focuses your attention. You can reach for a cup of coffee or something, but you really can’t drive, you can’t walk effectively. You have to commit to reading.

Fundamentally, there a haptic – tactile feedback – aspect of reading, even on the Kindle or iPad, that’s important to keeping you engaged. It gives you something to do with at least one of your hands, and that engagement with the hand is the clue to your consciousness that you need to pay attention to what you’re doing. These haptics also extend to the all-important question of navigating the book. Again, with a real book, or with a Kindle or an iPad, you have a physical gesture on the item to turn the page, find the table of contents, and so on. And if you want to highlight a passage, or share it, or go back a few pages to reread that last part, you need a way to do all those things. When interacting with the air this becomes a disembodied gesture at best. And you’re not going to be able to do that just with your eyes, I suspect. And of course both books and iPads are opaque – the rest of the world may appear around the book, but not through the book.

In the interview with Charlie Rose, referred to in my earlier post, Sebastien Thrun showed an interaction of reaching up to the Google Glasses to push a button. But I think that’s not really going to work in the end. Not only is the gesture clumsy, because you can’t see your own hand at that point, but it’s also really obvious, where you might want some ability to be more subtle. And it’s only a single button – can you really get all the necessary interactions into a single button? Steve Jobs couldn’t – that’s why he invented multi-touch for the IOS devices.  Note that the most successful devices of all time – including the pencil, book, and iPhone – require visual engagement – they can’t be operated simply by touch.

But even the IOS devices have a problem – no feedback to your actions. This is a big problem for me when I’m using the iPad or iPhone as an input device, for example. I’m a touch typist, but on the iPad there’s no way to know if I’m touching the right keys, so I have to use my eyes, which slows me down.

A Proposal – A Smart Slate

Assuming my concerns are rational, how might you address this issue in a Google Glass era? You’re going to want to have something with which to interact, that has some physical presence, and that perhaps can even react to your touch. What I’m imagining is a “smart slate” type of device, on which the Google Glass device, or other devices like it, “project” the images for items that need a physical presence to be most useful, such as books, keyboards, “Minority Report”-like displays, and touch interfaces.

The glasses would keep track of the location of the slate, and always make sure the images are projected correctly for the current orientation of the device. If the slate is moved, the images are moved at the same time. If the slate is tilted away, the image tilts. If the user swipes the slate, the page turns, or the table of contents is loaded, depending on where the swipe occurred. The slate could be instrumented to tell the glasses about the swipe, or the glasses could use a Kinect-like capability to detect the swipe visually. In a more advanced version of the slate, it could provide haptic feedback, using one of several technologies that are becoming available for programmatically changing the texture of a surface, such as this technology from Senseg which may appear in Samsung smartphones soon.

This is an example of something I’ve called “rematerialization” – a play on Daniel Burrus’s recognition of “dematerialization” as a central driver in the future. With digital technology we have dematerialized books, but in reality they’ve been rematerialized as Kindles and iPads. Because we humans exist in “meat space,” we still need our “stuff” to exist in meat space, even if it’s not in quite the same form as it used to be. And while our books may dematerialize even more, out of Kindles and iPads into Google Glasses, there’s still going to be a need for meat space interface for us to interact with them.

That’s What I Think – Now It’s Your Turn

What do you think? Are you looking forward to reading books floating in the air, or do you think there will still be a physical device when all is said and done?

Product Management Rules of Thumb 3: It Has To Work

Your Product Has a Job – It Better Do It

I just subscribed (again) to Mark Hurst’s “Good Experience” newsletter. He dropped me an email the other day asking how I’d heard about the list (I don’t remember, actually) and why I subscribed. As I wrote out my response, I thought it would be something worth posting as well.

My product philosophy holds that two critical factors for a product to be successful are

  1. It has to work – to do what it’s supposed to do, to “do the job it was hired to do”
  2. It has to be engaging – people should look forward to using the product

The “good experience” concept covers both of those factors. Hence, naturally, I want to continue to get information and inspiration about good experience.

There are other aspects to beating your competitors, but these two particular points seem particularly obvious to me. But, I’ve always been amazed at how many products don’t do well on either score.

If The Other Product Fails To Work, That’s An Unbeatable Competitive Advantage

With my last product, we would go into head-to-head evaluations with our competitors, and our product would work in the evaluation phase, and theirs wouldn’t. Competitors failed along a continuum – from not being able to complete an installation in the first place, to not successfully performing the basic functions, its reason for being. If your product does not work during the evaluation, then you are likely not going to win the business!

But If The Other Product Works, Yours Had Better Be More Engaging!

Some products failed later than others, but even if the other product didn’t fail, we almost always won the evaluation anyway. That’s because our product was better, in a key sense – it was more engaging to use. In that particular product space, most products approached the problem in a certain way that was, you might say, the “standard” approach. Our product approached the problem in a different way, one that turned out to be easier for customers both to understand initially, and to work with over time. So we not only won the evaluations because we worked, but because the customers liked us. As Kathy Sierra puts it, we made them feel like they rule!

What Comes After Google Glass? (Part 1)

Some Thoughts On The Future of Reading

Like any good technologist, I’m very interested in the future. I’m waiting anxiously to hear what Tim Cook will say this week at the Apple Worldwide Developer Conference, of course, but for this post I’m going to look a bit farther in the future.

Google Glass has been in the news lately, including an interview with Sebastien Thrun of the GoogleX research lab on the Charlie Rose show, where he showed the Google Glass device and even kind of demonstrated it. The fundamental idea of Google Glass, apparently, is to put a virtual layer over the real world to enable people to do cool stuff without interacting directly with a traditional device like a mobile phone, tablet, or laptop.

A question that occurred to me was how will people read in a Google Glass world? And by “read” I mean long form items like books, magazine articles, and so on – not the messages that come up on a phone screen.

Humans Remain Humans (At Least For A While)

Even in the future, there will be some “fixed points” of human behavior. For example, people will still be talking to each other. And they will still be reading books and long-form articles, and a smaller group will still be writing. But just as today we have many more ways for people to talk to each other than our ancestors did 100 years ago (i.e., the phone, text messages, email, video chat, and so on, in addition to the basics of speaking face-to-face), in the future there will be even more new modes by which people are talking.

The same is true for reading. We’ve gone from hand-written books before Gutenberg, to hard-cover books for several centuries, to broadsheets, to paperbacks (as an addition to hardcover books), and lately to Kindles and e-readers (again, in addition to the physical books), as well as audio books.

In the activity of talking to people, we’ve essentially dematerialized the conversation – you don’t have to be in the same place as your interlocutor, and you don’t have even speak.

Do We Need A Device? Not Technically

Today, we still need a physical artifact – a book, or a magazine, or a device – to read (versus listen to) a book. In the future, is there any reason that people need to read books on a device at all? Or on a device that’s so ubiquitous that it’s not really a device, such as Google Glass or its tenth generation descendant (Google Contacts)?

Well, there’s no question that this will be possible, and it will definitely be the way we consume some reading material, just as today I do occasionally read books on my iPhone, when my iPad or Kindle is not handy.

In fact, there’s no intrinsic reason it has to be a device. It could be a reengineered brain that hijacks the visual signal and adds something on it, like a book.

This is one vision of “the brave new world” of augmented reality, and as I say, there’s no technical reason this can’t happen.

Pitfalls Ahead?

But while I think this is an awesome and cool vision, there are some potential practical pitfalls, which I’ll talk about tomorrow in a follow-on post. In the meantime, what are your “visions” for the future of reading, and for anything else related to Google Glass?

How to Prioritize: Top 6 Prioritization Techniques

Too much to do

As a product manager, one of your fundamental challenges is prioritization. You have a lot of things – features, enhancements, new products – you want to do, and not enough resources to do them all.

Whether it’s the list of features and capabilities you want to implement in your product, or the customers you want to visit and get insights from, or the anthropological studies you should be doing with prospects in your market or the market you want to get into, you will not be able to do everything you want. This means you have to prioritize your activities. You have to prioritize what you ask from your developers (i.e., in terms of features). And you have to be able to defend and justify your priorities to your supervisors, to the business, and to the people who are executing the work you have specified.


Prioritization is a critical capability for product managers

Here I outline some of the basic concepts of prioritization. We’ll explore these in more detail in future posts. I’m not going to cover everything there is to know about prioritization. But I give you a number of techniques that (typically in combination) you can use to help you make better decisions about what to do.

Better, at any rate, than simply flipping a coin. Of course, nothing is guaranteed. As many a product manager has discovered before me, you can make the best decisions in the world and your product may still fail for reasons beyond your control. But if you want to have the best shot, here are some of the things you should think about.

Techniques of prioritization

I’m going to write this as though the priorities were new features for your product, but the same ideas work for other things you might need to prioritize:

  1. Trust your instinct – more on this in a future post, but remember that one of the reasons you are a product manager is that you have specific expertise about the product, or the space, or about decision-making per se. So your gut feelings are likely to be decent. On the other hand, if you’re like me, you want something more concrete to backup your decisions.
  2. Analytics – either qualitative or quantitative. The types of analytics you can use to support your decisions varies widely. For example, if you have talked to several customers about a new feature, and they’ve all said it would be highly valuable to them, and your gut says most customers would get value from it, that might be enough “analytics” to move forward. Analytics can get a lot more sophisticated, of course. People use spreadsheets comparing the revenue outcomes for different combinations of features, and tools that graphically illustrate how well a set of requirements satisfies a set of prioritization criteria based on a market model. There are tools that use “option pricing” and other advanced financial techniques to give you a numeric priority value. Analytics are the best tool in your toolbox for defending and justifying your decisions.
  3. Stack ranking, and ignoring things at the bottom of the stack. Part of being a good prioritizer is not getting weighed down by the stuff you’re not going to be able to do, no matter how desirable it is. One way to help you achieve this clarity of mind is to stack rank your new features. The most important ones – determined, perhaps using your gut instincts backed up with some analytics – are at the top. Then just ignore everything in that list after the first ten items. This is a fundamental technique from agile software development. Once you have decided what is the most important feature to deliver, concentrate on delivering that feature and ignore anything else that’s lower in priority. Once the most important feature is delivered (or complete and ready for delivery), you can revisit the stack-ranked list. Review the ranking, make any changes necessary, and then focus again just on the top items.
  4. Doing tests with a “minimum viable product” or MVP – sometimes you have an idea of whether a feature or a tactic will be valuable, but you need validation from the market that your instinct – which we can call a hypothesis in this case – is correct. As in real science, you test a hypothesis with an experiment. In the world of lean software development this experiment is sometimes call an MVP – a minimum viable product. The phrase “minimum viable” means “the minimum amount of development needed to test the hypothesis.” Sometimes an MVP is as simple as a webpage, while sometimes it can be a complete development project in itself. It completely depends on the hypothesis you’re testing. The point is that you are not doing any more work than you have to in order to find out if your hypothesis is correct or not.
  5. What’s the worst thing that could possibly happen? The process of prioritization always has winners and losers. One way to test whether your prioritization is correct is to do a thought experiment. For each of the candidate features, ask yourself, what is the worst thing that can possibly happen if we don’t deliver the feature? You can use the answers to this question for each feature to minimize the worst possible outcome. Of course, it’s possible that not delivering a new feature won’t have a bad outcome, but delivering it would have a very positive outcome, so you can’t use this as your sole decision-making criterion.
  6. Make sure that your boss’s pet feature is handled. This may sound a bit cynical, but remember that you’re not just optimizing your development team’s efforts to deliver value, but you’re also optimizing your own career. Your success depends on you delivering good products and on staying employed and keeping your boss happy. If your boss has a feature that he or she really wants to see in the product, then that feature has extra weight in your prioritization – you might still cut it, but you need to have an especially strong story for why that had to happen.

What prioritization techniques do you use?

That’s a few quick ideas on how to do effective prioritization of features into a release. You can also use these tips for prioritizing anything in your career (or life). Let me know in the comments if you make use of these techniques or if you have other prioritization tools you like to use.

Product Management Rules of Thumb 2: The Three Boxes Rule

New Products Improve Processes

Earlier I mentioned one of the rules of thumb I use as a product manager to help me assess whether a product idea is worth pursuing – what I call the “order of magnitude” rule of thumb (in short, your product needs to offer an order of magnitude improvement over the status quo). Another simple rule of thumb I like to use is what I call the “three boxes rule” (even though the picture I draw actually has four boxes!).

The goal of your product is to improve some process of the customer’s. This is true even for innovative products like the iPod, which improves the “walking around” process by adding music to it. SAP improves the customer’s business management process overall by providing a central repository for the data and a predefined best practice workflow for doing back office information processing. Photoshop improves the photograph editing and manipulation process by taking it out of the darkroom and eliminating the need for scissors and paste.

Actually four boxes illustrating the old process and the improved process.

The three boxes – make sure A still links effectively to B’, and B’ links effectively to C

Improving the process is all well and good. But this rule addresses the fact that processes don’t live on their own – there are processes that come before and that come after. In the case of Photoshop, for example, there is the predecessor process of taking the picture, and of getting it into the computer. And then, after using Photoshop, there is the process of putting the picture into a magazine or newspaper layout so it can be printed.

The diagram above summarizes the situation. Box A represents the predecessor process, box B is the process we’re going to improve with our product, and box C is the successor process. The improved version of B is shown as box B’.

Now that we have our boxes, the rule of thumb is apparent: It doesn’t matter how good B’ is compared to B, if you can’t get from A to B’, or from B’ to C, your product will have a hard time succeeding. (This concept is related to the idea of the “whole product,” covered in many books about product development and management, such as Crossing the Chasm by Geoffrey A. Moore.)

Example: Photoshop In Its Infancy

Photoshop is the product that got me thinking about this rule of thumb. Coming up with the idea for Photoshop required a flash of brilliance, as well as the availability of some technical capabilities like personal computers and GUIs. But once you have the idea, the details are going to work themselves out. “Hmmm, I need to be able to crop, recolor, touch up, burn, dodge, copy a section from one picture to another picture, etc.” In fact, most of the functions of the original (20 years ago!) Photoshop were computer-based analogs of what photo editors were already doing in the darkroom or on a paste-up board. I don’t mean to minimize the work or design that went into the functions of Photoshop itself, but the reality is that the functions were secondary to a much bigger problem.

Before Photoshop, when you edited or retouched a photograph, you worked with … a photograph or a negative. A piece of paper or a piece of emulsion. For some activities you needed a separation – three pieces of plastic. To make a copy of a photograph you either printed a new one from the negative, or you took a picture (a photostat) of it. When you were finished editing it, you pasted it into a layout, then took another several pictures of the whole thing to create separations that could be used by a printer.

However, to work with a photograph using Photoshop, you had to have a digital version of the photograph. And at the end of using Photoshop, you still have a digital version. Nowadays that’s not such a big issue. But when Photoshop was first released, B’ was fantastic, but it had a severe impedance mismatch with A and C, which were based on paper.

Mismatches To Watch Out For

There are lots of ways for impedance problems to arise between A and B’ and B’ and C. Some examples:

  • Platform mismatch – the preceding process is on Windows, while your new and improved version of B is on the web.
  • Technology change – this is the Photoshop example – the improved process uses a different type of data from its predecessor.
  • Unfamiliar look and feel – the existing process lives in a client-server world, while the improved version is Web-based.
  • Legacy data integration – my product replaces an existing solution, but the customer still needs to work with their old data.

Many products fail because, no matter how good a job they do at B’, customers can’t get to B’ from A or to C from B’.

Adobe realized that Photoshop could not be successful just by being a fantastic replacement for traditional photo retouching – it also had to address the interface with the old paper methods preceding and following the touchup process. Adobe managed this successfully, obviously, and that makes it an incredible example of the product manager’s art.