Rich Mironov reposted his great article, Magical Thinking and the Zero-Sum Roadmap, about the physics of roadmaps yesterday at the same time I posted my closely-related tidbit about delivering late being better than delivering on time but with low quality. Not a surprising coincidence, since getting product out there is something that occupies our minds tremendously. Rich summarizes his key point as Mironov’s Roadmap Theorem #1: “You can’t put something new into the current development plan without taking out something of equal or larger size.” And that’s a law of physics. Just because the software you write doesn’t need to obey the laws of physics doesn’t mean that the laws of physics don’t apply to its creation.
Predicting the Future – Another Name For a Roadmap
We all love roadmaps, at least our bosses do. They want to know what’s going to happen in the future, and usually they also want to know how much of you’re going to sell, and how each individual feature is going to pay for itself. If you think back to my “Radically Different Manifesto For Agile” post of two weeks ago, you’ll recall my first thesis was “It’s fundamentally better to not try to predict the future. Do your best to predict only as little of the future as you can get away with.” The other points in the post align with that, all based on the ultimate point – predicting the future in detail is impossible. This is a statement we all agree with, right?
Of course, you can predict some big things, what Daniel Burrus in Flash Foresight
The Creative Act
So, we know that the details of the future are impossible to predict. But that’s compounded, at least in the software world, by the fact that software doesn’t obey the laws of physics. Another way to say this, as Kurt Leafstrand did in his Medium article Don’t Build, Compose, is that in a software startup, “You’re writing a novel, not constructing a bridge.” Or, not to put too fine a point on it, creating software is not engineering in the same way building a bridge is.
Software is a creative endeavor, more like writing a novel. I talked about this last week in Product Management and Fear. There is no right way to get to the goal, for every new feature in your product you’re starting with a blank page, and you’re likely to go down a lot of rat holes before getting to a form that’s delightful and delivers value. In the article Leafstrand says engineers often need to “tweak the storyline a bit.” I’d go farther – “tweaking” doesn’t quite capture it – I’ve heard authors describe needing five completely different drafts of a novel – different tense, different voice, different characters – before they find an approach that works. As product people, our fantasy is that we’re only a few tweaks away from success, but sometimes we need to shift gears completely in order to make progress. (Hell, every paragraph of this blog post has gone through at least three edits!)
We are therefore put into a difficult place – we want the ability to predict the future (that is, a roadmap), we have constant pressure to add to the roadmap without changing the dates, and we’re writing a novel, in practical terms.
Roadmaps Become Perceived As Reality
And then, unfortunately, the roadmap usually transitions, in peoples’ heads, into reality. Our best guess at predicting the future, which was at best always optimistic, becomes the expectation outside of the product team. In the meantime, inside the product team reality is asserting itself and we are doing our best to deliver the most value we can using agile to prioritize the most important features first, and striving to avoid what I wrote about yesterday (delivering something “on time” but crappy) and instead deliver something incredibly useful, engaging, and that people will buy. On whatever schedule that takes (within reason).
There, in a nutshell, is why product management is not just a fun job, but a tough one. If you can dance that dance, and not get fired, and still get software out, and love doing it, you can be a product manager.
Generally speaking, all else being equal (and don’t tell anyone I said this) the release date of a particular version of my product is not that important to me. In the long run no one remembers if a release was late. What everyone remembers – the customers, technical support, sales engineers – is when a release was incomplete or buggy. That’s what will lose you a customer, and it’s how the product team loses the respect of their colleagues.
Therefore, as a product manager, I’m have to be more concerned about the customer’s experience than the company’s short-term desires, especially about release dates. The company might want a release to come out on a particular date, but if it will jeopardize an important customer’s experience, I can’t allow that to happen. And in the end, the customer is more important. Losing a customer is very costly, while shipping a few weeks late to make sure a product is actually ready is not very costly. It does impact the schedule of the next release perhaps, but less than the fire drill of the emergency fixing of bugs you actually shipped.
I’m interested to hear your thoughts on this – do you sacrifice schedule for quality, or have you managed to figure out how to drop features for time?
My topic today is fear – how fear is the number one problem that product managers face. Well, I don’t know if it’s number one, but it’s definitely up there! A big part of our job is dealing with uncertainty – and even when things look “cut and dried,” they usually are not. This means every decision, every action, every statement we make is a creative act. And you know what happens to creative people – they get writer’s block, they get stage fright. They get “the yips.” These are all fear-based problems.
Of course, we have a lot of best practices. We know that requirements are a best practice, but we also know that a lot of successful products have been delivered without much in the way of requirements. We know that prototyping is a great way to converge on a product design, but there are lots of products that don’t have much design that do OK, and lots of beautiful products that sink like cannonballs. We know that having a well-articulated value proposition is a great best practice, but we know lots of companies that manage to do without them, at least initially.
We are creatives, therefore we have fear
And in any case, the problem with all those best practices is that they don’t eliminate the fundamental creative obstacle – whether you’re talking requirements or prototypes or value propositions or any other best practice. I’m talking about a blank space that has to be filled with something, something out of your own head. A requirement needs to be filled with words, a prototype is a design even if only made from the merest nothings. A value proposition is a terrible, daunting Mad Lib that this product is for “something” and for “someone” and it’s better than “that thing” because of “this thing.”
Not only do you not know what to write to fill those empty spaces (even if you do, it seems like you don’t, in the moment), but there’s also the fear about what happens when you do write something. Once there’s something down, then (you fear) everyone feels great about telling you how to change it, how you missed this, or should expand on that, or how could you think that was the right approach?
Are you fearful, or is it just me?
Does any of this resonate with you? Or is it just me who faces the writer’s block every day? Who worries with every word if it’s going to be wrong, and drive the company into the ground, or be roundly panned by my colleagues, or the engineers? Or have I indeed hit on a thread that, so far, hasn’t been explored much in the macho product management blogosphere? Of course, I have the same fears about this post as I do about any requirement I write – am I off my rocker, or mentally ill to be even be thinking this way (or to admit that I think this way)?
Well, I’ll leave you to consider that over the weekend while I start work on the second installment of this series – what can we do about this fear? I have some ideas, and I’ll run them by you.
One aphorism about creating great products is “write the datasheet first.” This is kind of a lean startup concept – write the datasheet and see if anyone likes it well enough to call you up and try to buy the product. It’s a kind of minimum viable product.
But I also like to take the opposite approach, and imagine “what if?” This actually works whether you are planning to build a product, or looking to buy one. “What if my product were out there and it was really successful – what would people be saying about it, why would they have bought it, and what kind of value would they be getting?” Or, “If I found the ultimate solution to my problem in the market, how would I be thinking about it, what would it be doing for me, and what might I tell other people about it?”
The obvious way to capture these ideas is in the form of Amazon reviews (five star, of course).
So, since I’ve been thinking about product management tools lately, from *both* perspectives – builder and, more recently, buyer – I thought I’d share some of these Amazon reviews. I emphasize, in case it wasn’t clear, these are made up – they are me imagining “what if?”. So here are some of those great five-star Amazon reviews for the product of my product manager dreams – ProductManagerPro.
- ProductManagerPro Gives Me Analytical Backup For My Decisions
By A Solo Product Manager
“Using ProductManagerPro, I was able to start making much better product decisions, and then to make sure that my decisions were being properly carried out. Before I had ProductManagerPro, it’s true that I made those product decisions to the best of my ability, but I was never able to justify my decisions on anything beyond my strong (albeit well-educated) gut feeling. Having ProductManagerPro to back me up on these decisions has given me a lot more credibility within the organization, and has given me a lot more confidence that I’m doing the right thing. Add to that that I can now track how those decisions are progressing through my product development process, and I’m a very happy camper!”
- ProductManagerPro Enables My Team To Do A Better Job and Keeps Everyone Aligned With The Product Vision
by A Manager Of Dozens
“I have a staff of tens of product managers and almost 100 developers. When my organization decided to go with ProductManagerPro I had my doubts – another management tool that, if we spent a lot of time on it, all overhead, my managers might get some useful information, but it wouldn’t help me at all. Well, those doubts were cleared up in the first few weeks when I found I was finally able to see what really was going on in my organization. ProductManagerPro’s information is at the sweet spot between high level strategy and low-level user story development, and allows me to see how the work my team is actually doing – whether it’s development or product planning – relates to the high level goals of the department and even the company as a whole, and not only whether we’re on track against those goals, but whether we’re aligned with them over time.”
- The Developers On Our Team Love It!
by A Die-Hard Agilist
“As a developer, I thought ProductManagerPro was really not for me. I’m all for my product managers having a better tool than Word or Excel, and in fact I knew that automating some of what they were doing could help me out. But ProductManagerPro has surpassed my expectations. It turns out that it hasn’t added overhead to my process (thanks to the integration with our IDEs, I can get my tasks provisioned right within my development environment), but it’s given me a lot more information about what I’m working on and why. Sometimes people think us developers just want to be told what to do and then be left alone, but I find it very motivating to be able to see why I’m working on a particular little item, and in fact I think that knowledge helps me do a better job, because I understand a lot better how this function will be used, what other capabilities it integrates with, and how it relates to the overall goals of the company and the users using our product. In fact, because of ProductManagerPro’s great collaboration abilities, I’ve also been able to make suggestions to our product managers for enhancements or improvements to functions I’m working on, which they have agreed to, and which I know have been popular with some customers! And this could not have happened nearly as easily without in the picture.”
- It Helps Me Be A Better Product Manager, Right Out Of The Gate
by A Newbie
“I am a new product manager, having transitioned from an engineering role, and I found at ProductManagerPro really helped me make that transition in my organization. They had configured the system in a really good way so that I knew exactly what information I need to provide, in what format, so that me and my colleagues could make good decisions, and so that my old colleagues – the developers – could get the most value from the system. This ability to configure the system to match our business processes made a really big difference to how quickly I was able to ramp up, and also it kind of gave me – and I think the rest of the team – some ‘secret sauce’ for doing a better job.”
- Enables Us To Automate The Only Business Process That Creates Money
by A Numbers Guy and Executive
“My company realized a few years ago that now that we’d implemented ERP and CRM, the only real competitive leverage we had left to automate was our product planning and development process itself. Of course, this is obviously the hardest thing to automate, but it also gives the most leverage, because a successful new product can really change the landscape for a business. So I started researching solutions for improving our product management process – about 100 product managers working with about 250 products and product modules and 1,500 developers. A lot of the solutions were clearly just toys when confronted with the scale of our operation. But ProductManagerPro was architected to address the kinds of problems a company like mine faces in the product planning and product management process.
We’re now one year into the implementation of ProductManagerPro and we’re seeing lots of improvements in various areas, although we’ve still got a long way to go. Just getting our requirements into a central system of record – in a scalable way as ProductManagerPro allows us to do – has been huge. It’s turned our product planning process into an enterprise asset, whereas before, when requirements were scattered across various “systems” – mostly Word documents and Excel spreadsheets – there was no way to consider them an asset. And the visibility that ProductManagerPro has given our executives, from product VPs to C-level execs, has resulted not only in our ability to catch problems while they are still imminent, rather than emergent, and has also given the top execs a lot more confident that the product teams are aligned with the corporate goals and objectives. That in itself has made the company a much more pleasant place to work!”
Do You Have Tricks For Creating A Product Vision?
What techniques do you use for helping create a compelling product vision? Have you tried writing a review of your (future) product from the perspective of your ideal customer?
Also, if you’re a product manager or a development manager, don’t you just wish someone really would give us this ProductManagerPro package?
I do not like the agile manifesto. It does not resonate with me as a product manager – someone responsible for guiding successful products to market. It’s very focused on the needs and desires of developers, and much less so on my needs and desires, or more importantly, on those of my customers and prospects. But, I love agile, and I believe agile – and its follow-ons, like lean and kanban – are critical to enable people like me to create and deliver new products that create value in the world.
My Six (Not 99) Theses
What is it about agile that turns me on, while the agile manifesto itself leaves me cold? I’ve made a stab below (and made other points elsewhere) at a high-level explanation for why I like agile and why I think it works. It’s based on some tenets or axioms that lead to the conclusion that an approach like agile is generally superior for delivering value than more traditional approaches like waterfall. I guess these are my version of a manifesto, one that leads to agile and lean when they are applied to product development:
- It’s fundamentally better to not try to predict the future. Do your best to predict only as little of the future as you can get away with.
- It’s fundamentally better to be responsive to changes, especially as change happens so fast.
- It’s much easier to predict how long it will take me to do one thing than it is to predict how long it will take to predict multiple things.
- Don’t try to predict where you’ll be a long time in the future. Instead, keep your prediction interval as short as possible – you’re much more likely to be correct. (E.g., if I travel at 50 mph on this road for 15 minutes I can predict with great certainty where I’ll be, but if I have to predict where I’ll be in two weeks’ time, I could literally be anywhere!)
- Predicting what the market will want far in the future is extremely difficult, so instead do your best to only have to predict what the market will want in the near future.
- “Work in progress” is fundamentally a type of waste – this is a tenet from lean manufacturing and the Toyota Product System, but it also applies to software. Software that’s been developed but is not in use by customers – the definition of “work in progress” for software – is wasteful. Even if it eventually provides value for customers, it’s not providing value right now, leading to an overall loss of total value, which is undesirable. Note: This also applies to requirements – a fully fleshed out requirement that no one is working on is waste, so my recommendation is “don’t do that.”
If you combine those tenets “agile” naturally pops out: Don’t focus on optimizing a large set of work, instead focus on completing the most important piece of that work, as quickly as you can, and deliver it. Since you’re only delivering a small chunk, you don’t have to predict very far into the future. And you’ve chosen the most valuable thing to work on, so you know your market will want it. Because you are working in small chunks, if the market changes its mind, you can quickly change your plans in response. And by always having only a small amount of work in progress, you reduce waste and create more value.
Agile, Upon Analysis, Turns Into Lean and Kanban
In this analysis, though, it’s not really agile that pops up, it’s lean, or more accurately, “Kanban” (at least as practiced in software development). No matter how long your sprints are, some of your features will take longer than the sprint length to deliver to the 80% level. This is a big problem for agile methodologies, because a feature that’s only at the 60% level (which perhaps you can get done in one sprint) doesn’t provide significant business value, and usually neither you nor your customer gains by delivering it at that point. (There’s clearly another blog post in this topic of 60% value versus 80% value.) And therefore Kanban’s approach, which I will simplify as “take your three most important features and work on each one feature until it’s deliverable, then deliver it, and then start on another feature,” does a better job of delivering value to the market and reducing work in progress.
I’ve used the term “lean” above, and I’m really talking about the concepts that come from lean manufacturing. But these ideas are also intimately tied to the “lean startup” mindset as well. One of the key insights of the lean startup is that instead of guessing or predicting the future (all the things I’ve said you don’t want to do), you create hypotheses and test them, getting real data about how customers respond to your product and its features. Agile and lean and kanban again perfectly align with that approach:
- Get “finished” work out to the customer as soon as possible to find out if they like it – after all, there was a hypothesis that drove the feature or whatever it is, and you want to test whether the hypothesis was correct or not. If so, yay!, and your customers are going to be more successful faster. If NOT, then yay! You have learned something that you can immediately address without letting the issue wither on the vine.
- Instrument the product so that you can understand how it’s used over its life. This way you can find out what users do with the product, how they’re using it, where they’re running into problems (using the same techniques as webmasters use to assess the usage and obstacles of their websites).
- Getting features out earlier means that you can get paid for those features faster, whether this is due to existing customers expanding their installations, or renewing their maintenance, or due to new customers coming on board because they heard from their friends (or via an evaluation) that the product does more of what they need better. In other words, more features earlier means a better top line. And the top line is the one that grows the economy – both yours and ours.
Do We Need A Product Managers’ Agile Manifesto?
I don’t know why I feel the need to reinvent things, like the agile manifesto, but there you go. I’d love to start a conversation about this, and if other product managers resonate with my ideas here, perhaps we can refine them and put out our own manifesto on how to deliver more value to market, faster.
The Eternal Agile Question: Product Owner or Product Manager?
I’ve been thinking agile lately, and that whole question about the “product owner” versus the “product manager.” Which should you have (or should you have both?) and what do they do? As I’ve mentioned before, the key analytical point to remember is that agile – and the “product owner” concept – came from internal IT development projects, where the project was generally for a particular business unit. You could get a representative of the business unit – a real product owner – to come and represent its needs in a reasonable way. That person’s idea of what was important was considered trustworthy, and so that person could effectively make the prioritization calls. In other words, it was one person, and they knew what the priorities should be, because they were experts in that actual application.
The Types of Projects
Contrast this with two other types of development projects that are out there in the world. There’s the “F-22 Strike Fighter” type of project. In this project, the customer (the U.S. Defense Department, for example) develops a set of requirements that is then farmed out to contractors to implement. The goal of this project is to end up with a product that precisely delivers on the requirements as spelled out in the requirements document, no more, no less, and to do so at high quality and in a reasonable amount of time. And if there is a change to the requirements, it requires renegotiating the contract as a whole. Prioritization in this case is pretty easy, at least in the base case – the contractor has to implement everything in the requirements. That’s it.
Then there’s the type of project that I work on, which is a commercial software product. In this case, the company producing the software, and in particular, the product manager, creates the requirements. (If we’re doing “agile,” of course, we focus on the most important ones initially.) It’s pretty easy to define a whole universe of features that could go into the product, only a fraction of which we are capable of implementing in a timely manner. So the fundamental activity of the product manager, after coming up with this huge list of features, is to prioritize the list with the goal of having the most successful product when it gets into the market. There are lots of tools for this – lean startup is one great approach – but at bottom it involves developing a deep understanding, or at least a deep set of analytical tools, as to what the market really wants, what it is ready to actually buy, and so on.
Product Owner Is The Wrong Abstraction for A Commercial Product
The key point, when it comes to talking about a “product owner,” is that in the third case, commercial products, there is no product owner. There is no one person who knows what the product needs, whose decision is always assumed correct, and who can truly represent the universe of users. The product manager, rather, becomes a channel to the market, the set of users, and has to use techniques and skills to translate what the market wants to what the product should do.
In the spirit of agile, these are admittedly somewhat rough distinctions, but they are qualitatively on the mark.
- An F-22 type project has relatively little prioritization needs, but it has a lot of need for traceability, especially to testing and quality issues.
- An internal IT project has more need for prioritization, but there’s assumed to be one person who is capable of doing that prioritization and whose answers to prioritization questions are directly inspired by the usage of the product.
- Then there are commercial products, where prioritization is a fundamental, deep, and very difficult issue, because there are typically lots of unknowns, there is competitive pressure, and so on. No one person can play a “product owner” role out of his or her head or based on his or her experience, but instead needs to actively engage the market and channel its needs and desires.
Agile Is Powerful, But “Product Owner” – Meh!
I don’t mean to imply that agile is meaningless in the context of a commercial product. I’m only addressing the product owner concept. As I’ve written about several times, an agile process is an intrinsically better approach to developing something of value than a waterfall process, even large features, because its nature is to ensure that delivery of value is front-loaded.
I’m curious whether others have struggled with this product owner vs product manager question, and what you’ve concluded. Please share your thoughts and let’s have a conversation about it.
Good software is a meal, not a kitchen
When you go to a restaurant and order a dish, you expect the chef to make a dish that’s ready to eat, without you having to specify anything. And generally speaking, that dish is going to work out great for you. Sometimes you might be on a low-carb diet, and you need to ask them to “hold the bun” or something like that (understanding that the chef might not be able to accommodate you). But normally, the chef sends you something good and you eat it, and you don’t need to make any modifications in its configuration.
That should be one of the goals of our software as well. The user should be able to “order” a feature or function in the software, and the software goes ahead and does that feature or function in the right way that will make the user happy and solve the problem and create business value. If the user has to make some modifications to their order, they can, but those changes should be the exceptions, not the rule.
Developers like making stuff, so they give their users kitchens
The natural inclination of software developers, though, is to make software that’s highly configurable, where the user has to make a lot of decisions every time, and the software itself makes as few commitments as possible as to what the “right” way is. Or, to use my metaphor, it’s as though the software is making the user a chef, and providing a full kitchen, rather than taking on that responsibility in the software and allowing the customer to enjoy to well-prepared dish.
I find myself coming up with these stories, like comparing our product to a restaurant, to give the developers tools for thinking about the software in ways that will help them make good decisions about usability without my help. Of course I want them to come to me when they have questions, but by giving them better instincts on usability – and metaphors are a good way to do this – they are much more able to come up with good solutions themselves.
What are some of your favorite metaphors for improving the instincts of your developers? By the way, a hat tip to Alan Cooper (@mralancooper) who used another restaurant metaphor – about an excellent waiter – to talk about software politeness.
(First published back in 2010, this article is still apropos and I thought it was time to revive it.)
Managing big features using agile
This post originated as a comment on the Cranky Product Manager’s blog, responding to her post on agile methodologies. She said
Yes, Agile can speed up the development and improve the quality of small features. But it’s too often at the expense of the Big Important Work — the heavy lifting, multi-month market analysis and architectural work that lead to REAL customer value and REAL competitive differentiation.
I magnanimously offered my perspective on agile, boiling it down to the key points of:
- Do the most important things first
- Be prepared to reprioritize on a regular basis as the environment changes
Or, “spend your resources on the 20% of capabilities that will get you the best return.”
So far, so good. Can’t argue with that as an approach, not just for developing software, but for living life itself. And for the self-help industry, which generates tens of thousands of pages on the Pareto Principle every year. And I’m sure CPM, as we call her, was super-happy that I clarified that.
How waterfall falls down
In contrast, the old way (aka “waterfall”) is more like:
- Figure out what you want to accomplish
- Determine the most efficient way to accomplish it
It’s easy to see waterfall’s problems when characterized this way:
- You have to know up-front what your end game is – which makes it hard to respond to market changes
- The most efficient way of building the full product is not necessarily the one that front-loads the value, so often low-value items are completed and high-value items end up deferred
- You do a lot of work up-front to document things that the developers never get to
Notice that’s not how agile talks about itself. The agile manifesto talks about working code vs. documents, and interactions over tools (it does cover “responding to change”). In fact, agile, as far the methodologies and manifesto go, is solely focused on programming. (This is changing some – I just listened to Kent Beck’s talk at the Ruby On Rails conference last year, and he’s come up with a very different characterization of the goals of agile: it provides accountability, responsibility, and traceability.)
How agile lets you tame the big dog
Now, given my characterization of agile’s – indeed, life’s – key goals, you can then look at agile methodologies simply as one way to accomplish those goals. But what if, as CPM fears, the most important capability (call it The Big Dog) takes longer to deliver than a sprint or two, and requires visits to lots of customers to understand their problems, and lots of reviews with customers to see if we’re solving their problem?
Clearly, you still have to do the Big Dog. CPM should be able to tell you why. And if the methodology doesn’t give you a way to do it, then the methodology won’t work for that product.
But chances are the 80/20 rule applies to the Big Dog, just as it applies to everything else. And this large monolithic capability can be broken down sensibly into multiple passes through the “smallest thing that could possibly work” approach. Does this require the PM to keep ahead of the development organization? Yes. Is that any different from the old days? Yes and no. The PM needs to figure out the most important part of the Big Dog (the 20%), and make sure it’s understood, there are good user stories, it’s designed, architected, etc., extremely well. After all, that’s where most of the value is going to come from.
But the PM doesn’t need to document the rest of the 80% until later – if at all. In fact, it’s likely that finishing the 20% of the Big Dog prioritized to the top of the project leaves something else – the Medium Kahuna – as the next important item to accomplish. There may be some additional Big Dog-related capabilities that are “nice to have” – and they’ll be prioritized into the rest of the project, if there’s time after getting the Medium Kahuna delivering its value.
“Now wait,” you (or the CPM) say, “I can’t live with only 20% of the Big Dog – I need 100% of it – or at least 80%” And I say this is where the beauty of the agile mindset comes into play. If you’ve completed 20% of the Big Dog, and have the rest of the Big Dog as well as the Medium Kahuna in your backlog, at this point you can decide which is more important, and decide which one to do. You’re already delivering 80% of the value of the Big Dog – now you can decide if you really need to take that up to 90%, and leave the Medium Kahuna on the table, or vice versa. You have control.
Agile can’t solve every problem, but can tame a lot of big dogs
Agile is not a silver bullet, and it’s hard to get right, but if it helps you focus on putting first things first and executing on the 80/20 rule, it’s done its job.
Your thoughts?
A mess o’ games (photo by Eric Mallinson, CC 2.0 license)
Comments Are Good!
I was chuffed to get a long comment from Kathy Sierra on my last blog post, about how gamification of enterprise applications aligns with Dan Pink’s “Motivation 3.0″ as he describes it in his book Drive. I’ve been a big fan of Kathy’s for many years, since I first discovered her “Creating Passionate Users” blog, and then listened to her many talks that are available via IT Conversations and other places on the web. (An annotated bibliography of Kathy’s good stuff is below.)
Kathy took some exception to my admittedly simplified descriptions of the components of Motivation 3.0 – mastery, autonomy, and purpose. And some of her points were welcome clarifications to what I sketched in my post.
Any attempt to use external regulation for anything that might EVER be intrinsically motivating is a dark path, and one I would strongly reconsider if I were looking into enterprise gamification. Gamification claims to be taking “what is good about games”, but it is actually doing the opposite. What is good about games does NOT lie in the mechanics (look at the oldest game — one still extremely popular throughout much of the world — the game of Go. It has all the essential ingredients for Motivation 3.0, and almost none of the surface mechanics), but rather in the core experience which IS intrinsic motivation: it feels good to do it for its own sake.
First of all, I completely agree with her that the fundamental challenge we have in gamification of enterprise applications is that adding extrinsic rewards to a knowledge-based activity can have the extremely counter-intuitive effect of reducing the intrinsic motivation to do that activity. As I’ve said over and over in this series of posts about gamifying enterprise applications, I’m assuming that the users are already well motivated, intrinsically, to use the apps and to do a good job. So gamifying them is not about increasing their motivation, but rather about achieving other important goals that enterprise applications (indeed, most other applications) do not do well, but which gamification can do a good job of.
So let’s rephrase what our goals for enterprise gamification are. There are three problems:
- Getting attention – that is, competing against all the other distractions, whether they are hallway conversations or Facebook, or doing expense reports
- Getting feedback, especially enabling feedback
- Making the interactions more fun, engaging, satisfying, pleasant
Which summarize to one big goal, in Kathy’s own terms:
- Enabling them to “kick ass” at their work
As Kathy notes in her comment:
Games often make excellent use of feedback, but it is the feedback in games, not that they are games, that makes them so good at creating higher skills. Feedback is an absolutely essential element for developing competence (and ultimately mastery), as virtually all learning and improvement happens as a result of high-quality, low-latency feedback.
And that’s the key component of what I’m suggesting we learn from good games in our gamification of enterprise applications.
Again, I’m not trying to motivate people to do a good job (they are already motivated to do that, and I don’t want to mess with that intrinsic motivation), but I’m trying to:
- Help them make the decision to leap into the work, which is the only way you get into flow
- Help them get into flow by removing obstacles and making the experience more engaging
- Help them know when they are doing a good job or have done a good job, so they can be constantly improving – think of this as supporting “deliberate practice.”
- Help them have a better time doing the thing that they already want to do – this is like giving a musician a better instrument, or a photographer a better camera – they can’t always take advantage of all the improvements, but it’s just easier to learn to play guitar, for example, on a good instrument that’s well set up than on a cheap instrument that’s always going out of tune and has terrible action.
Work is always hard, or it should be, but it should be just as hard as you can actually accomplish, and not easier, and not harder, in order to make maximum progress.
Heading Toward A New Categorization of Gamification
As I’ve pondered this conversation with Kathy, and what I’ve learned in Kevin Werbach’s (@kwerb) Coursera course on gamification, I’ve realized there really are two threads or rivers of gamification. I’m calling them, for now “coercive” and “encouraging” – I’m sure there are better words, especially for the latter type. Specifically, I’m partitioning these as follows:
- There’s the set of things that we don’t want to do but we need to do (e.g., fitness and new habits fall into this category for some) or that someone wants us to do (e.g., visiting a marketing website, slow down on the road). That’s the realm of coercive gamification.
- Then there’s the set of things that we want to do, and we’re motivated to do, but we sometimes need some help in doing them as well as we’d like, or in getting started, or in keeping going, or in truly getting into flow or getting engaged, or in knowing how well we’re doing, or what we need to do in order to get better. This is the domain of “encouraging” gamification.
It’s very possible that this distinction has been made already, and I’m just rediscovering an already well-known map, that even has correct place names. If so, I’m sure I’ll hear about it in Werbach’s course in the next few weeks!
In any case, I expect to spend a lot more words on these concepts in future posts.
Also, I just found another recent post from Kathy on a very similar topic, responding to a post by Larry Ferlazzo on gamification in education. Similar concerns, and very apropos of this discussion.
My Favorite Kathy Sierra Stuff
Now, as I mentioned, I’ve been a big Kathy Sierra fan for a long time, and I’m always happy to have a chance to share her awesomeness with the rest of the world. Here are some of my favorites from her:
Of course, there’s her blog, Creating Passionate Users, which is an archive at this point, but I highly useful archive. Some of my favorite posts are:
- Attenuation and the suck threshold (A gem among gems)
- A crash course in learning theory and its accompanying summary
- Featuritis vs the Happy User Peak
- Usability through fun
Her talks (most of these are audio only, but some videos) – all worth the time spent watching/listening and learning:
- How To Kick Ass, from the 2008 O’Reilly Emerging Technologies Conference
- Creating Passionate Users from the 2011 O’Reilly Tools of Change Conference – also available as a video on YouTube
- Cognitive Seduction from the 2006 O’Reilly Open Source Conference
Comments Are Open!
OK, I’m looking forward to hearing about how far off base I am – let ‘er rip! (In the comments.)
