Sep 16

Product Management And Fear – Three More Powerful Creative Blockbusters

Several years ago I had an article about three powerful tips for getting through a creative block. Although focused toward product managers, the tips were general purpose ways to increase your creative output.

  1. Morning pages
  2. Crappy first drafts
  3. “Use Your Obvious”

You can summarize the three tips pretty easily, despite their variety – “Just Write!”

At right around the same time I drafted this post with more tips that are especially applicable to product managers. But I just found out I never posted it! So here it is, a little late, but still pretty useful, I’d say. (Well, I still use these techniques anyway!)

Use multiple modalities

More than most other creative domains, product management is a multidisciplinary activity. All of our work has a technical aspect, a creative aspect, such as the UI, a marketing aspect, the sales aspect. And this gives you powerful tools to unblock your creativity. If you’re blocked with writing a requirement, you can design a UI, and so on. I call this approach to your creative problems “multimodal.”

If you get stuck on one mode, you can often get started on another mode and continue to make progress. And because all the modes are interdependent, making progress in one area often frees your mind up to make progress in other areas.

Suppose you are working on a new feature, but you’re not quite sure how to articulate the user story for the developers. Instead, you might attack it from a different perspective. You could start by describing how the user would experience the feature, how it would help his or her day-to-day life. Or you could start by writing down some technical constraints on the feature. What technology would be used, or how it would interact with other existing features to make sure no value is lost? Or, in a very traditional approach, you could start by writing the datasheet for the new feature. And of course you could start by sketching out a user interface.

(And remember to apply all the rules from the previous article, especially “crappy first drafts.” Your first drafts are often not going to be usable. But they’ll give you insights to use for your second and final drafts. )

Conceptualization tools

So far, I’ve described techniques that help you create the actual content of your requirement or marketing piece and all related components.

But, as my friend Scott Gilbert (with the awesome Twitter handle @AgileProducMgr) mentioned in a comment on LinkedIn, you can also use tools that help you conceptualize the problem. A novelist might use a story board, a timeline, and a cast of characters to conceptualize his or her novel. These all help develop the story, and prep for, but do not precisely achieve, getting words on paper.

We can use those techniques as well, in exact analogs to the novelist’s story board, timeline, and cast of characters. We can explore the timeline of the feature and how it fits into the process flow in the application. We can list the users of this new feature (or as they’re often called, the personas).


 As I determine if my design supports different aspects of politeness, I move the aspect to the Yes branch, with an annotation saying how it's polite in that way.

As I determine if my design supports different aspects of politeness, I move the aspect to the Yes branch, with an annotation saying how it’s polite in that way.

Another tool that works very well for conceptualizing a new feature is a mind map. I use a free mind mapping tool called Freemind. Scott uses MindJet, a commercial product. We both got a lot of value from creating mind maps. They help us understand not only the problem we’re trying to solve, but also how the solution might come together. They are great for addressing the -ilities like usability and scalability.

I created a mind map template to help me with user experience and interaction design aspects of my features. My template outlines the key aspects of user experience as described by Alan Cooper in The Inmates Are Running the Asylum (including the 17 aspects of politeness). I use the mindmap to make sure I have good answers to every aspect as I’m designing the feature.

Next Up – PM-specific Tools, Not Just Techniques

In this article I focused on techniques that are well-suited to product management’s multiple modalities. A later post in the series will be about tools that are specifically designed for PMs and how they can help overcome creative blocks. (Unfortunately, as you’ll see, some of those tools so far only exist in conceptual form – that is, in my mind.)

Apr 14

Structured Vs. Unstructured – What PMs Can Learn From Mozart

Don’t be like this guy! (Image by Christina, CC 2.0 licensed)

There’s always a balance between structure and lack of structure. It plays out in every domain, and especially every creative domain. Structure can help us think, can help us remember (i.e., be an offboard memory), and can give us guidelines within which to be creative.

Consider the classical composers – Bach, Mozart, Beethoven – each had a structure in which they composed, and part of their greatness was creating the greatest of works in that structure. The other part of their genius was in breaking the rules of those structures and extending the structures to accommodate new thinking and new avenues for creativity. We might not have had a Beethoven if Mozart had said “let there be no rules for music anymore!”

But, on the other hand, we wouldn’t have had a Beethoven if Mozart had only followed the rules he got from Bach. Breaking the rules, even while mostly playing within them, characterizes most important creative work across history. Even transgressive artists start from a structure – in fact, their transgression is only meaningful in opposition to the structure it transgresses.

The point is, some structure – the right structure – is good. History has shown that it’s better to have structure, but to break out of its rules sometimes, than to have no structure. ([tweetthis hidden_hashtags=”#prodmgmt”]It’s better to have structure but break the rules sometimes, than to have no structure.[/tweetthis]) And as the Heath Brothers discuss beautifully and at length in Decisive, you have to break your structure sometimes to enable creativity.

You have to strike a balance. Most tools “designed for” PMs are too constricting (see my earlier post on the danger of treating product management as a list management problem). But in contrast wikis are too freeform – they don’t help you think as a product manager, but just as a thinker. Without enough structure, it’s easier to leave stuff out of your thinking that you should be including (see my post about Impact Areas, for example). This is even more true if you want some analytical ability – analytics depends on structure.

Let me know what you think about structure and lack of structure in the comments.

Mailing List Signup

Sign up for my mailing list to make sure you don’t miss any of my posts!

Jan 14

Start With The Simplest Thing That Could Possibly Work

Start with the simplest thing that could possibly work.

A simple, crappy sketch I made once

A simple, crappy sketch I made once

This is an agile concept (actually from Extreme Programming, technically), but it’s great for helping you get unstuck from any creative problem (see other tips here and here). You have to simply resolve to not worry about whether your design is going to be any good, and just go ahead and do the design. Or the writing. Or the coding. Whatever it might be. The goal is to get the first draft done. First drafts are usually awful, but you can’t get to a good second (or third, fourth, fifth, hundredth) draft until you’ve written the first draft.

For example, if I have to design a new user interface component (and I’m not a designer at all!) I will just take a pen and paper, or use Balsamiq, to create a rectangle that’s going to be the outside, and inside it I’ll put the buttons and fields that seem to me at that moment to need to be there. My only goal is to get something that could possibly, in some limited fashion, capture or present the information that was necessary.

This is the only effective way I’ve found to get going on design problems. Since I’m not a designer, I always have a “block” against designing. As a user of many many different interfaces I have some intuitive sense of what’s good and bad. But I try not to use that sense at all when doing this exercise, because my goal is only to get something that could possibly work down on paper (or into Balsamiq).

Once I have that first crappy design, then I can start mucking with it, improving it, reviewing it with others, and so on. In fact, by getting started in this way, if all the other conditions are right (i.e., it’s not too noisy and I don’t have other distractions) I sometimes go into a flow state and get very involved in creating an actually good design. But I have to start with the first draft, which I know is going to be terrible, and is just something that could possibly work.

What do you use to get unstuck?

Jun 13

4 Great Features That No Product Management Software Has – TL;DR Version

Earlier today I posted a pretty long article about how product management is a lot like writing a book, and that we should look to what tools writers use to help us figure out what capabilities tools should have to make a different for product managers. For those with too much on their plate, here’s a TL;DR version of the earlier post.

Writers use tools that help them capture ideas and rearrange them, elaborate them, and refine them until a story emerges. And they form groups, go to retreats, cultivate readers, in order to have a collaborative environment. Their “process” (there is no real process for complex activities like writing) involves writing crappy first drafts and then revising, reworking, reshuffling, reconceiving, and other re’s. Writing a novel is by turns about idea gathering, prototyping (crappy first drafts), collaboration (writing group), and iteration (multiple drafts) process. And the outcome is emergent, not predictable or plannable.

4 Features That Product Management Software Needs

Given all that, here are four capabilities or activities that really helpful product management tools would support – in addition to capturing our user stories:

  • Help us iterate, elaborate, and rearrange on our ideas and features in a more managed way
  • Help us collaborate
  • Help us get past the “blank page”
  • Help us remember to use our creativity unblockers

I have a lot more thinking on this topic, which I’ll get to in future posts. In the meantime, if you think I’m on the right track, or on the wrong track, or just smoking dope, I’d love to hear your thoughts about product management tools and complexity.

Jun 13

4 Features Of Great Product Management Software – That None Has

I said last week I’d write about why the complexity of product management means we don’t have good tools (yet). This is a complicated, perhaps complex, story in itself – which is not surprising, given that it’s a complex domain.  

Update: If you have a a limited amount of time, read the TL;DR version of this post.

Product Management As Writing A Book – An Extended Metaphor

As a way to approach product management tools and what we need from them, let’s think about the tools that writers have for writing. I’ve argued already (along with lots of others) that product management is a lot like writing a book – a good product, like a novel or biography, reflects a big, coherent idea, expressed in an appealing, engaging, comprehensive way, where all the strings are tied up the end.  Whether a book is well-written is apparent from the first page, and only the good ones are really satisfying – or make a difference in the world.  

Tools for writers are few and far between, and they fall into a few main camps:

Corkboard (image by http://www.flickr.com/photos/forestfortrees/ – CC 2.0 licensed)

This taxonomy is over-generalized, but the point is what these tools do is allow writers to capture a lot of ideas and rearrange them, elaborate them, and refine them until a story emerges. They do not do much for helping the writer make the creative leap. None of them focus on unblocking the creativity of the writer, except to the degree that they allow you to progress without actually writing (e.g., by making a mindmap, or an outline, or by rearranging cards, all of which can help in overcoming a creative block).

And they are not about automating a process in the normal sense of the word – first do this, then do that, then do this other thing if some condition exists. Once the book is written and accepted for publication, then there’s a process with steps, but not until then.

Many writers also form groups, go to retreats, cultivate readers, in order to have a collaborative environment.

Writers proceed by writing crappy first drafts and then revise, rework, reshuffle, reconceive, and other re’s. Writing a novel is by turns about idea gathering, prototyping (crappy first drafts), collaboration (writing group), and iteration (multiple drafts) process. And the outcome is emergent, not predictable or plannable.

And defining a product is the same. One of the many valuable ideas that agile methodologies surfaced for the product process is that a user story is the beginning of a collaboration, and only through that collaboration – with the developer, with the eventual user, with other stakeholders – is the feature defined. The Lean Startup concept says that your ideas are hypotheses that need to be tested with experiments to learn their value. Jeff Patton’s story map approach takes us even closer to the world of writing tools, essentially providing a good way to “corkboard” our user stories.

The Advantages of Being A Product Manager Versus An Author

On the other hand, as product managers we have a couple of major advantages over novelists. For one thing, we don’t have to produce art to be successful – as long as our product is significantly better than its competitors, better at providing value, better at fitting into the customers’ processes, better at doing its job – it will can be successful, even if it’s not a Hemingway or a Franzen.

Our other big advantage is that we are already part of a team. Novelists don’t have a group of people who are rewarded for helping them create an excellent, marketing-leading novel. This gives us a big leg up on the collaboration part of the story.

4 Features That Product Management Software Needs

Given all that, here are four capabilities or activities that really helpful product management tools would support – in addition to capturing our user stories:

  • Help us collaborate
  • Help us get past the “blank page”
  • Help us remember to use our creativity unblockers
  • Help us iterate, elaborate, and rearrange on our ideas and features in a more managed way

I have a lot more thinking on this topic, which I’ll get to in future posts. In the meantime, if you think I’m on the right track, or on the wrong track, or just smoking dope, I’d love to hear your thoughts about product management tools and complexity.

May 13

Product Management And Fear – Three Tips For Overcoming Creative Blocks

A few days ago I said that fear is one of the big problems product managers face, in our creative role of finding new solutions to new problems. Much of the time we’re looking at a blank page that we need to fill with requirements or a datasheet, or a blank screen that we need to put a user interface on, or a blank set of slides that will eventually be used to sell our product. And a blank page is a recipe for fear – fear of failure, fear of not coming up with the right solution, fear of missing something obvious, or just fear that this time the magic isn’t going to happen.

A big part of the literature of creativity is focused on how to overcome fear. In other domains they call it by different names – writer’s block, or stage fright, or creative block. I find many of those techniques are valuable, and some I use every day (like morning pages). But there are also product management-specific techniques that can help. And there are some product management tools that, if they existed, would help overcome fear. Today I’ll start with some of the techniques I use that come from outside the world of product management.

General creativity techniques

  1. My favorite of these is morning pages, from Julia Cameron’s The Artist’s Way (highly recommended!). The basic idea is to write three pages every morning, first thing, as fast as you can with no editing and no judging, just pouring out the words, even the words are “I can’t think of anything to write.” More often though, the words will eventually start coalescing around a topic, often the topic about which you are blocked. At least, that’s my experience. Cameron describes morning pages as three pages, handwritten. I typically do my morning pages on an awesome website called 750words.com – three pages handwritten is about 750 words – which tracks my writing over time, and makes it fairly easy for me to reuse it if I come up with something good (which often happens). The site has a number of “gamification”-like features, like giving you badges for streaks of different lengths. I’ve now added my own challenges, such as attempting to write 1,000 words or more per day on average. I find that my creativity really starts to kick into gear, if it’s going to, between 600-800 words, and if things start rolling, it’s pretty easy to get up to 1,400 words in a sitting.
  2. Related to morning pages is the timeless advice from Anne Lamott, in her book Bird by Bird – “Write sh*tty first drafts.” Or as I like to clean it up a bit – Write crappy first drafts. This is actually not a directive, it’s just a fact that your first drafts will not be what you want them to be, and so you should expect that and not get worried when your first attempt is a piece of crap. What’s amazing is that you can attack that first draft, and turn it into a second draft, and it’s likely to be a lot better, and the draft after that even better. And even if the first draft doesn’t lead directly to a second draft, at least it will help you think through your idea so that you can create another (but less crappy) first draft in a different direction, but with much more knowledge about the landscape of the idea.

    The two techniques above are focused on writing, but you can use them for any creative effort. I often will do something like crappy first drafts for UI concepts. I don’t expect to do a good job of user experience design on my first mockup, but I always learn a lot and at worst I get a sense of what additional things I need to start thinking about in order to make a better experience.

  3. Finally, “use your obvious.” This is a new technique for me, which I got from a great list of nine creativity sparking tips from Marelisa Fabrega (I was turned on to this list by Kate Matsudaira (@katemats) in her excellent Technology Leadership News newsletter). I find it incredibly useful. The basic idea is that what is obvious to us about a particular situation is not necessarily obvious to other people. In fact, that what’s obvious to us is actually our differentiator, to use a very product-management word, it’s why we got the job in the first place. The way I use this is to just write down what’s obvious to me at first. That might be innovative enough, and it’s certainly a good start. To provide value I don’t have to necessarily invent something new – I just need to get my own insight into the world.

Coming up – PM-specific creativity unblockers

I will continue this series tomorrow with some more product management-specific techniques for overcoming fear and creative blocks. Let me know in the comments how you handle creative challenges in your work, whether it’s coming up with new product ideas, or designing UIs, or writing marketing material. 

May 13

Product Management and Fear

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.

Jun 12

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?

Jun 12

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!

Jun 12

How to Prioritize: Top 6 Techniques

Too much to do

As a product manager, one of the fundamental issues you will have in your life is that you will have a lot of things to do, and you won’t be able 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, and what you ask from your developers (i.e., in terms of features), but you also 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

In this post I outline some of the basic concepts of prioritization, which we will explore in more detail in future posts. I’m not going to cover everything there is to know about prioritization, but give 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, to 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, with the most important ones – determined, perhaps using your gut instincts backed up with some analytics – and then 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), then 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, which in the world of lean software development has come to be called 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, and 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 very possible that not delivering a new feature won’t have a bad outcome, but delivering it would have an 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, or in general how to prioritize 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.