4 design lessons we can learn from U2 concerts

If you’re a designer (or just into good design) and a music fan, I’d like to recommend the book U2 Show. The book is about how the various U2 tours were designed — from Boy all the way through Elevation. It explains the countless hours that go into stage design, lighting design, sound & speaker stack design, and a whole bunch of other areas (and it has some great photos too). I really enjoyed the window this book provides into what goes into the design of a large rock concert, and it showed me again that basic principles of good design translate to all media forms.

Here are some things I believe the design community can learn from the way U2 design their shows: (more…)

In defense of compliance

There is a very interesting and healthy debate going on in the Agile Development world about Minimum Viable Product (particularly in startups).  Before I get into the topic I’d like to address today, I just want to do some positioning and say that in this debate, I currently (but am open to being convinced otherwise) side with writers like Andrew Chen (read his excellent post, Minimum Desirable Product) and Jason Cohen (read Releasing Early Is Not Always Good? Heresy!).  The other side is represented by posts like this one by Jeff Atwood: Version 1 Sucks, But Ship It Anyway.

While the debate is still ongoing, I’d like to write about a very specific related aspect, namely product development process (and those of us who would like to argue for fairly strict compliance to it).  Two recent blog posts address the topic of compliance directly, and I wanted to reference them and then write a quick response on why I think process is so important, especially in agile development.


3 Product Management lessons from Comcast’s new sign-in pages

As a Product Manager, I understand the Minimum Viable Product (MVP) concept, decisions to de-scope rather than delay, etc.  But too often MVP’s go out into the wild missing that all-important middle “V”, so you end up with, well, minimum products.

An example I came across recently is the sign-in process on Comcast.com.  First, a little background.  Comcast recently deployed a product they call mySIGN-IN.  According to their FAQ page:

mySIGN-IN is a unified sign-in system that lets you use your existing email address and password to access participating Comcast sites. When you sign in to any participating Comcast site, you’ll be conveniently signed in to the other sites that you use.

That all seems well and good, but the actual sign-in experience shows what happens when features go out without proper integration.  The sign-in process now happens on two separate pages:


Netflix doesn’t know me: How I lost faith in recommendation engines

When Netflix first came out with their movie recommendations, I thought it was a great idea. I started rating movies I’d seen — good and bad — confident that the brain behind it all will do its magic and recommend some hidden movie gems that will, you know, change my life. Well, I’m still waiting for those movies. And to be honest, I’ve become a little bit frustrated with the whole thing.

Describing the latest example I encountered will reveal how much I liked a movie that I probably have no business liking, but I’m willing to sacrifice a little bit of my reputation in the name of science, or whatever this is…

The first problem I encountered is a pure UI issue, and has to do with how Netflix shows the star movie ratings on their pages. As an example, this is what I see for the movie August Rush in my queue:

You would assume that the customer average rating is just over the 3-mark, right? Well, looking at it closer, it turns out that Netflix shows you a rating they call “Our best guess” (3.4 in this case), instead of showing you the customer average (4.1 in this case):


7 Essential Productivity Tools for Product Managers

As Product Managers our job is to gather information from a variety of different sources, make sense of it all, and then turn it into cohesive product visions and execution plans that end up growing the business exponentially (yes, we’re superheroes).  And we wouldn’t do it if we didn’t already love bringing order to chaos.  But sometimes we need a little help.  Below is a collection of software (mostly Mac-based) that I have found essential in my day-to-day PM work and helps me to always have a handle on what is going on in my projects.

I have broken these down into three categories:

  • Tools for project management. These are the programs that are always open on my Mac.  It starts with a high-level overview of all projects, and progressively gets into more detail and specifics.  I can’t imagine staying on top of all my parallel tasks without these.
  • Tools for wireframing. No designer wants a PM to tell them what a design should look like — and for good reason: it’s not our job.  But sometimes you want to put some of your design thoughts on paper, without being too prescriptive on the execution.  These tools help you do that.
  • Tools for collaboration. These are the tools that increase productivity by freeing documents from your hard drive and putting them in the cloud so you can work on them in collaboration with other stakeholders.


Email is dead. Long live email.

There has been growing discontent with email over the past year or so, but it appears that many people’s hatred for this particular form of communication has now finally started to boil over.  Several articles and blog posts over the past few weeks lamented the death and/or evilness of email in no uncertain terms.  In this post I go into a few highlights from said email hatemail, followed by some thoughts on why we shouldn’t be so fast to close down our email accounts.

The problem with email is…

First, a disclosure.  The excerpts below are just that: excerpts.  While I attempt to keep the context and the original intentions of the authors intact, I encourage you to read all these articles in their entirety.  They’re not only thoughtful and well-written, but they also lay a solid foundation for what I think is a very worthy and much-needed debate.


Toward a universal model for software product development


I’ve seen a lot of product development processes over the years, and as with most things, it’s important to take what works for your organization, and leave what doesn’t work.  These processes go by different names, mainly various combinations of the words Product Development Lifecycle (PLC or PDLC).  There are also a common thread through most product development models, and this article assumes that the reader has a basic understanding of the general five steps of product development:

Great work has been done on fine-tuning the details of the PDLC, but it has always bothered me that there is not one universal model for software product development that fits two main criteria:

  • Specific enough so that it gives real and practical guidance for product managers and organizations on how to design and develop good product.
  • General enough so that it can be applied to all different types of software development methodologies (Agile, Waterfall, Spiral, etc.)

And that is what I set out to do in this article. (more…)

What MSN Mobile can teach us about good design

As designers and user experience practitioners, most of us can look at web interfaces and immediately tell the good ones from the bad ones.  The good ones are usually an indication of execution built on a collaborative and equal effort between different groups and stakeholders.  The bad ones usually point to one of two things:

  • The site was chopped up and different teams owned different parts of the same pages without a clear plan for holistic design; or
  • Somewhere along the line relationships turned sour, decisions got escalated, and one of the groups/stakeholders won a contentious argument about the design of the product.

I came across one such example of poor execution today while browsing the MSN Mobile web site on my iPhone.  Here is what I saw:



  1. 1
  2. ...
  3. 166
  4. 167
  5. 168
  6. 169
  7. 170
  8. 171