I recently realized that you don’t hear the word “globalization” all that often any more.  And I think it’s because globalization has moved from being a buzz word to a reality that is just part of the way we do business now, making it unnecessary to give it a fancy name.  As we become more comfortable with managing companies and projects across multiple locations, it’s easy to assume that geography does not matter any more.  And certainly the technology is there to support the around-the-clock collaboration that is so valuable when you work across time zones.  With cloud computing now a reality, and plenty of collaboration applications to choose from, working together has never been more efficient.

But I believe geography does still matter, and can result in decreased efficiency if not managed correctly.  The difficulty with working across multiple locations is not technology limitations, it’s human nature.  We tend to not trust what we can’t see, and that’s a problem if developers, product managers, and marketing folks sit in different offices and different time zones.  Once different work philosophies come out and you’re not able to talk about it, things can escalate out of control and make for really bad relationships if conversations happen intra-office but not inter-office.

This is not an insurmountable problem though.  Here are some things I believe can help distributed teams run smoothly.  Please also add your tips and ideas in the comments section!

1. Meet in person. Now.

People get along so much better once they’ve shared a meal together.  This is just a fact of human nature — we thrive on in-person social interaction (yes, even us introverts).  If you have distributed teams, it is imperative that they meet each other in person as soon as they start working together.

If a trip can be planned during a major software release — even better.  Nothing binds people together like the stress and exhilaration of getting a new product out in the wild.  Work hard, but also make time to go have dinner together.  You’ll find that after the initial trip, you’re able to understand each other a lot better over IM/phone calls.  I do think it’s worth getting teams together at least once a year, but even if it’s just once at the beginning of the relationship, it will go a long way to improve working relationships.  So go ahead, spend the money on that trip.  It’s worth it.

2. Be respectful of time zones.

10am in San Francisco is 8pm in Cape Town.  Not a great time to have a meeting… Now, it won’t always be possible to line up time zones, but at the very least it’s important to trade off meeting times.  Don’t make the guy in the smaller office always dial in at 9pm.  Alternate between meeting times to give everyone a chance to have a life outside of work.  Try to have all night-time calls on one or two nights, not spread out across the week.  It’s the little things that count.

3. Use the right technology.

When it comes to collaboration across teams, there is no excuse for inefficiency.  We use the following applications, and I can highly recommend all of them:

• Google Docs and Dropbox for document collaboration
• Jira and Confluence (enterprise wiki) for bug tracking, product specs, and related discussions.
• Conceptshare for sharing and commenting on visual designs.
• Campfire for group chats during projects, and especially during product releases.  The Propane desktop app and the Ember iPhone app are great add-ons to Campfire.

4. Keep it human

One of the most important aspects of team dynamics — and especially distributed team dynamics — is not losing your sense of humor.  Even when things get really stressful, keeping funny alive is essential because it reminds you that there are real people on the other side of the phone line/email address.  And, of course, it relieves stress.

I’ll give an example from a project I recently worked on with a developer team in our Cape Town office.  They built an environment for us to test the new product flows, and the screens can live either in a website or a pop-up window.  The normal (boring) thing to do would be to put a link there that says “Open in pop-up” when you want to test the pop-up dialog version of the flow.  Instead, the developers called the link “Pop that collar,” and the following image appeared when you hovered over the link:

Now, I don’t know if they did this to amuse me or themselves, or a little but of both.  But for some reason the joke doesn’t get tired for me, and it made working on the project so much more enjoyable.  Always bring the funny on your projects.

5. Trust each other

A recent article called Forced compliance is an obstruction to discipline really got me thinking about trust within teams — especially distributed teams.  I agree with the author on how damaging it can be if team members don’t trust each other:

A forced compliance style of governance is a lot about trying to compensate for lack of trust and admitting that we are more likely to fail than succeed. On the other hand, discipline is not pain, suffering and anguish. It’s only sadistic if you implement discipline for nothing.

We need to trust our team members — they are (usually) smart people who do the things they do for a reason.  It doesn’t mean you don’t have tough conversations when someone makes a mistake.  But making a mistake doesn’t make you untrustworthy — who among us would be able to meet that bar of excellence anyway?  Ask questions before you judge…

6. Don’t stop talking, especially when you disagree

The book Crucial Conversations: Tools for Talking When Stakes are High is a must-read book about having those tough conversations when things do go wrong, or when disagreements arise.  At the heart of the book are tools to ensure that everyone on the team gets listened to, and that no discussions happen behind peoples’ backs.  I much rather prefer an open dialogue about a product disagreement, than having to find out 3 months after launch that someone on the team didn’t like the way we did things.  As Product Managers, our role is to gather information from a variety of sources and channel that into the best possible ideas and products.  How can we do that if we don’t listen to everyone?

I often remind myself that as Product Managers, we are not judged by the number of times we ask for input, or how often we change direction based on new and relevant information.  We are judged by the success of the live Product.  So why would we not want to hear everyone’s ideas upfront so that we can launch the best possible experience?

So these are a few principles I try my best to apply when working with teams on different continents.  But I have hardly figured it out, and we’re basically making this up as we go along.  I’d love to know your thoughts and ideas: how can distributed teams work better together?

I should probably get up, walk around, and have a cup of coffee before I write this post.  Or maybe a little righteous anger over something small is good for the soul?  I’ll go with the latter…  I recently ordered a 2010 calender from Runner’s World.  A few days ago I received the calendar, along with the invoice.  Their payment is handled through a company called Rodale.  I just went to pay my invoice at www.rodalequickpay.com, and the experience left me frustrated, and incidentally still in debt to Runner’s World.

I know this shouldn’t bother me that much, but let me walk you through the experience, and then make a couple of observations.

The Rodale order process

I typed in www.rodalequickpay.com (yes, the irony of the “quickpay” part of the URL is pretty thick), and arrived at this screen:

Immediately, this bugs me.  I just want to pay an invoice, I don’t want to have to create an account.  There’s also so much wrong about this design:

• There are two calls to action, and the affordance is all wrong.  The first text you see is “If you are a new visitor…”, but the “Create New Login” button is too far away, making it look like you should log in if you are a new visitor.
• The “Login” button… first of all, it’s “Log in” (action), not “Login” (noun), but let’s ignore that pet peeve for now.  The button looks different from the top button, and is also much smaller, resulting in a pretty confusing experience on this first screen.
• I don’t understand the text “Please use this site to pay orders in full” at the bottom.  Not sure why it’s needed, and not sure why it’s not at the top of the screen.  Who is going to read that far down?

But ok, since I am a new visitor, I decided to create a new Login:

Ok, this is where things get really out of control.

• I’m not even going to begin to talk about the copy.  “eMail” in one spot, “E-Mail” in another?  And “Thank you!”?  But I digress.
• The first big problem here is that account creation and invoice detail information happen on the same screen.  I should enter my account level information first, and then move on to my transaction level information.  Especially considering that…
• …It is extremely difficult to find your account number and invoice number on the paper statement.  First, the microcopy about where to find it is not useful at all.  There is no “appropriate button” to click, and the clickable text “On My Invoice” and “On My Statement” don’t look like links and actually don’t go anywhere when you click on them.  (Read this post at Polon, and this one by Joshua Porter about the importance of writing good microcopy on forms)

So anyway, I start typing in random numbers from my paper invoice just to see if I can get somewhere, and this is the error message I get:

Ok, now we’re getting somewhere.  Don’t know why it’s a browser error, but fine.  So I know I’m looking for an Account number of >10 characters and an Order number of >12 characters.  Turns out that’s not entirely accurate though.  The form doesn’t let you enter more than 10 or 12 characters depending on the field.  So those numbers should actually be exactly 10 and 12 characters.  Why doesn’t the error message say that?  “Can not be less than”?  But hey, we’re making progress.  Off I go to look for those numbers.  It appears I got my Account number right, because next I got this error message:

Ok, now we have in-line messaging, not browser error messaging.  But whatever.  I verified the crap out of that number, but I couldn’t get past this screen.  It actually makes me sad because I’m sure the payment page would have been a real treat to write about.  I tried to call the toll free number but no one’s there, so as of this moment I still owe Runner’s World $21.75.  I’m really sorry guys, I will pay you as soon as you let me.

The point I’m trying to make

So here’s the problem.  The Rodale website was put together to accept payment.  This is how they make money.  But there was absolutely 0 thought put into the user experience, so I was simply unable to pay them.  And look, I know it’s much easier to take a design apart than it is to create a good one, I get that.  But UX design is becoming a mature field now.  It’s 2010.  Shouldn’t we be able to get rid of designs like this, and demand something better? It’s not rocket science, it’s a methodical thought processes to design a good experience.  Form design is difficult to get right, but it doesn’t have to look like Apple, it just has to get you through the process without friction.

What do you think?  Is it too early to rise up in anger against designs like this?  If not, what can we do to “spread the UX”, so to speak?

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:

1. Don’t place limits on the design in the beginning

U2 tour manager Willie Williams on how the PopMart tour came into being:

There was also a very direct (and very rare) brief to me that this tour would be “˜design-led’, rather than being intimidated by scale or logistics. Having proved to themselves and to the world with ZooTV that, in terms of what can be toured, “˜anything is possibl’, U2 were of a mind that the only limits to be placed on the creative ambitions of this tour were to be financial ones.

This is a really good principle.  The time for realism and feasibility will come — but in the beginning, think big

2. Challenge the limits of possibility

On the impossible design requirements given to the sound engineers:

Mark Fisher’s frustration with years of stage design constrained by traditional loudspeaker stacks led him to propose that we should keep the huge video screen free from clutter by placing the entire sound system in one central ball. Most sound engineers would have resigned on the spot, but Joe O’Herlihy rose to the challenge of mixing a live show through what would essentially be a mono PA.

Even during feasibility discussions, it is important to challenge your beliefs on what is possible.  Involve the engineering team in the product discussion — and challenge them to test the limits too!

3. Let the content shine through

I like how they talk about the huge differences between the PopMart tour and the Elevation tour:

After the broad, churchy strokes of the Lovetown show and the sensory assault of Zoo TV and the garish, high-concept japery of PopMart, here are U2 playing their songs hard, straight and in your face.

If you’ve seen the Elevation tour, you know what they mean.  The show was tastefully designed, but without distractions.  Just like a web site should be.  Design’s ultimate goal is to get users to the content and functionality they need as easily and pleasantly as possible.

4. Don’t design in silos

The book goes into detail on the simplicity of the Elevation stage and lighting design:

Video is not something that can simply be added to a show, a fact that is the downfall of many otherwise potentially interesting stage productions. We are so conditioned to look at television that moving camera pictures automatically become the focus of attention.

Because of this they went with what they call “Unmediated iMag”, which means that the screens showing the band members would be static cameras, showing everything in black-and-white to avoid distraction from what is happening on stage:

This is why it’s so important for Product Managers to include all parts of the organization during design, and why holistic design is so important.  You don’t want your company’s organizational structure to shine through in your design.

Pick up this book at Amazon if you’re interested — with more than just pretty pictures it brings a great design perspective to the enormous live concert industry.

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.

The first is Seth Godin’s Dancing with entropy.  His rant on compliance actually inadvertently includes a pretty good description of what Product Managers do:

People are often paid to enforce compliance. The job is to ensure that everything is in its place, that errors are zero, that things are delivered on time and as expected. The random event is a problem, something to be feared and extinguished.

His main point seems to be that you should embrace the unknown, and “dance with it”:

Most people, though, the ones with great jobs, are in the business of dancing with entropy, not creating it. Take what comes, sort it, leverage it, improvise and make something worthwhile out of it.

I’m assuming he refers here to the definition of entropy as “a measure of the disorder or randomness in a closed system.” This is a great sentiment and we should all be able to deal with the unknown, but in practice, creating Ordo ab Chao during development can only happen effectively with proper product process behind it.  You can’t dance with entropy without bug tracking, if you catch my drift.

The second is a post by Aslam Khan entitled Forced compliance is an obstruction to discipline.  I respect him a lot for his forceful call for self-discipline in development, and I don’t doubt his sincerity at all when he writes:

Surely, we have learned enough from spectacular failures that governance does not give people an opportunity to exercise self discipline. When you give a person a chance to develop personal discipline, then forced compliance is unnecessary. With forced compliance, we force people into ignoring their own discipline because the system will “sort” it out for you. It breeds an attitude of “the system failed me and it’s not my fault”.

This is an ideal situation, and I agree with Aslam that personal responsibility is an essential quality for any developer — and PM, and designer, and human being, for that matter.  But personal responsibility is just not going to get you all the way there.  And by there I mean a product that is successful in the eyes of the company and its users.  I’m not arguing for the perfect product — there is no such thing.  But there is such a thing as desirable products that work the way they are supposed to and meet customer needs.  And for that, you need more than personal responsibility.

It is a mistake to think that process/compliance slows down development or inhibits innovation.  Compliance puts boundaries around what is within scope, and allows you to know when the product you’re working on is ready to launch.  Compliance also doesn’t mean that you don’t trust your team, or that you think people aren’t capable of working on their own.  It’s not about keeping tabs on people, it’s about making sure the product doesn’t get out of control.

By compliance I don’t mean an inability to roll with the punches and remain agile, but that a certain degree of process is needed.  In an earlier post on the software product development lifecycle I go into more detail on what I believe is a good process for product development.  I also discuss three outcomes recommended by Pragmatic Marketing: Requirements, Functional Specifications, and Technical Specifications.  I do believe we need this level of process, and compliance to it, to build great product.  We should embrace it, not fight it.  You know, dance with it.

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:

Step 1: Enter email address

Step 2: Enter password

Two things struck me immediately about this experience:

• There is no reason to split the sign-in process into two screens.
• The visual design of the two pages are completely different.

Wanting to give Comcast the benefit of the doubt, I started looking into this a little more (because, you know, what else am I going to do on a Sunday afternoon apart from listening to Amos Lee on vinyl).  I thought that maybe this was an acquisition, and they are just taking some time on the integration.  But no, as far as I can tell, mySIGN-IN is not an acquisition — it is an internally developed product.  So I think this is what happened:

• A separate Comcast division designed and developed the mySIGN-IN feature
• The different Comcast properties started implementing the feature onto their sign-in pages
• Due to technical reasons, the pages had to be split for Comcast.com
• There was no UX oversight to ensure design consistency (or no resources available to make necessary changes)

Now, it does appear that someone at Comcast realized that this is not an ideal experience, and decided that explaining the changes to users is in order.  It’s a noble idea, but as we know, most users don’t read anything that’s not inside or next to a text box.  Either way, here are some of the tool tips that were added:

That first tool tip really bugs me:

Due to some recent security improvements, we now require you to enter your user name and password in two separate steps.

That just doesn’t seem right to me.  Due to “security improvements”?  I may be missing something from a security perspective, but I just don’t see why the sign-in information can’t be passed through securely without splitting up the pages.

What this means for product managers

I don’t mean to pick on Comcast.  This type of thing is very common, and I’m sure I’ve made similar decisions in the past that results in a user experience that’s not ideal.  But I do think this example can teach us a few things about product management:

1. Product owners (those responsible for individual features) need Product Strategists to ensure UX consistency (see this article from Pragmatic Marketing about different Product Management roles).  mySIGN-IN was clearly design in a vacuum, which could have been ok if there was someone who made sure the user experience stayed consistent across properties.
2. Don’t leave out the “V” in the MVP.  I believe that Comcast didn’t launch a minimum viable product.  Splitting the login pages into two screens is unnecessary and confusing to users.  The MVP might be an incomplete product, but it should never feel incomplete to users.  Users shouldn’t be able to notice that something is missing.  There is clearly something missing here.
3. Tool tips won’t solve everything.  If I had a penny for every time I heard the phrase “We’ll just add some content to explain that to users…”  As a general rule, if you need a tool tip which links to an FAQ page to explain something to users, your design is probably not intuitive enough.  It cannot be stressed enough that users really don’t pay attention to a lot of text.  The average user sees a form field, and starts typing.  Your user experience should support that behavior, not try to change it.

I have no doubt that Comcast had the best of intentions here, and that mySIGN-in is probably a cool feature.  But without proper product management, even inherently cool features can become frustrating user experiences.  Let’s be the users’ champions when it comes to launching new features.

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):

Here’s the problem. I loved this movie. I’m giving it 4 stars. But since Netflix doesn’t know that I have a soft spot for modern musicals (despite how highly I rated the movie “Once”), the “Netflix brain” didn’t think I would like this movie as much as the average customer.

This is a problem you see often on sites where the UI does not give proper user feedback about what it’s showing you.  It took me a few weeks to realize they’re showing me “Our best guess” in search results, and not the true customer average. Now I have to mouse over to see the true average every time. Why? Because I don’t trust the brain any more. (By the way, this is just one example, but as I’ve looked into it more, I realized it’s a systemic problem for me — Netflix’s best guess is rarely in line with my tastes).

Incidentally, on Amazon.com, the average user rating is 4.5 out of 5 stars. Pretty good. So this is the problem then. There is such a wide range of tastes out there that it’s hard to know who to trust. This is the problem Netflix is trying to solve — let’s look at “users like you” and then show you that average instead of the overall average. You’re therefore initially more inclined to believe the “best guess” rating provided by Netflix, than the average consensus provided by all users. It’s a good idea, but the implementation doesn’t seem to be there yet.  (The discussion about the validity of 5-star ratings in general is a separate and very interesting discussion).

I say all this to make a simple point — it appears that the collective wisdom of all users does a better job of predicting if I will like a movie than the recommendation engine provided by Netflix. The question is whether it would ever be possible for recommendation engines to get to know you well enough based on your preferences. Maybe if it takes into account not only your movie interests, but also music, books, online activity, etc.? Yes it sounds creepy, but how else would Netflix know how much I like strange modern musicals?

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.

Tools for project management

1. OmniPlan ($150 from The Omni Group)

OmniPlan is the Mac version of Microsoft Project, except that it’s a lot faster to use so you don’t end of abandoning it in the middle of every project because of sheer frustration.  It lets you easily add projects and tasks, track progress, and add specific notes about each action if you need a little more detail.

2. OmniFocus ($80 from The Omni Group)

Describing OmniFocus as a fancy To-Do list (which it is) would be doing it a huge disservice.  It was designed from the ground up to make it easy to input thoughts very quickly (into the “Inbox” area), and then you can separate those thoughts into Goals vs. Tasks.  The tasks are then easily separated into Projects (which work like folders) and Contexts (which work more like tagging).  It is easy to switch views between Projects, Contexts, Flagged items, Urgent items, etc.  I basically start and end every day with OmniFocus.

One of the other huge advantages of using OmniFocus is the iPhone app.  It’s expensive ($20), but well worth it.  One complaint I do have is that it’s not as easy to sync as it should be, which is disappointing.  The only free way to sync OmniFocus Mac with the iPhone App is through sharing on a Wi-Fi network.  There is no central database that syncs automatically between devices.  But this is my only gripe with it.  As long as you have your iPhone on and connected to the same wireless network as the Mac, it works like a charm and cross-syncs beautifully.

3. Evernote (free for a basic account)

I was resistant to using Evernote at first, because I really didn’t know what I would use it for.  Now I’m not sure how I ever got anything done without it.  This is the ultimate cloud application.  It syncs seamlessly between the web site, other computers where you have it installed, and the iPhone app.

Yes, I know, it’s just software for taking notes.  But I use it in so many ways.   Meeting notes, web clippings (get the Firefox plugin!), photos of whiteboard drawings… the list goes on and on.  And the fact that it immediately syncs with your account means that your notes are accessible on all your devices, which really helps when you eventually sit down at your desk and have to make sense of all the stuff you put in there during the day.  Also, the price is right!

Tools for wireframing

4. OmniGraffle Pro ($200 from The Omni Group)

This is the Mac’s answer to Visio (except, you know, better again).  Whenever I start working on a new project, OmniGraffle is my tool of choice to diagram the existing flow and any proposed changes.  I also use this to provide a more visual representation of any data that we have on any of the flows/pages - analytics, CS, user research, etc.  This really helps to get all stakeholders on the same page so you can solve for the right problems.

5. Balsamiq Mockups ($79 for desktop version)

As I mentioned at the start of this post, PMs need to be careful about producing mockups.  But that’s what makes Balsamiq such a perfect piece of software.  It is an easy-to-use, low fidelity mockup and wireframing tool that allows you to get ideas on paper without any visual design elements.  This allows you and the designers to get on the same page without stepping on each others’ toes.  Here is a demo from YouTube:

<

p align=“center”>

Tools for collaboration

6. Google Docs (free)

I have been Microsoft Office free for a while now, and I haven’t missed any part of it.  Google Docs allow you to be truly collaborative on your documents.  You can start a document and other stakeholders can add to it, comment on it, change it, and it’s all saved in real-time.  One of the best features is that multiple users can edit at the same time.  This means that, for example, PMs, designers, and engineers can work on the same document, and come out of a meeting with a finalized spec.

One drawback is that there is very limited version control in Google Docs, so that would be the only word of caution - use file names wisely to provide your own form of version control.

7. Dropbox (free for 2GB of storage)

I haven’t met anyone who has used Dropbox and didn’t fall in love with it.  Dropbox is how you would design file storage if the personal computer didn’t start out with hard drives.  It allows you to store your files in the cloud and access it from any computer — and from your iPhone with the free app.

The iPhone app needs some improvement, particularly to allow you to add folders as favorites for offline viewing, but that is a small complaint.  Dropbox basically means that you can work from anywhere.

Now go and be productive

So that’s my list.  I’d love to hear what other PMs are using to stay on top of their projects, and what your experiences have been with using the software in this post.  Let’s go be (organized) superheroes now…

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.

In the article Why Email No Longer Rules”¦, the Wall Street Journal announces that email is king no more:

But email was better suited to the way we used to use the Internet””logging off and on, checking our messages in bursts. Now, we are always connected, whether we are sitting at a desk or on a mobile phone. The always-on connection, in turn, has created a host of new ways to communicate that are much faster than email, and more fun.

Caught up in Google Wave frenzy, Techcrunch laments the following in Google Wave And The Dawn Of Passive-Aggressive Communication:

Google Wave is not just a service, it is perhaps the most complete example yet of a desire to shift the way we communicate once again.  For many of us, email is simply not cutting it the way that it used to. It’s a sedentary beast in a fast-moving web. It uses old principles for management, and this is leading to overload.

Sticking with Techcrunch, in Relevance Over Time, Nik Cubrilovic argues that email sacrifices relevance in order to present items in a chronological order:

Chronological order needs to be abandoned in favor of relevance. Without relevance, our ability to manage large sets of information is inefficient. The technology for relevance exist today, for eg. spam filters are able to tell us what we definitely don’t want to read. Real world information retrieval and organization is based on relevance, either what somebody else believes is relevant to us, or what we decide is relevant. Newspaper stories are not laid out in the order that events took place and libraries do not catalog their books in the order they were published.

Jeff Atwood, in a post entitled Email: The Variable Reinforcement Machine, explains why he think email kills productivity:

Oh, sure, we delude ourselves into thinking we’re being extra-productive by obsessively checking and responding to our email, but in reality we’re attending too frequently to our own desire for gratification and sabotaging our own productivity in the process.

Why email is essential in business communication

After reading each of these articles, the same question kept coming to mind: How do these authors use email? They certainly don’t use it the same way I do.  Because I simply cannot imagine replacing email with Twitter and Facebook - and even Google Wave.  As far as I can tell, here are the major complaints about email:

1. Email is not real-time enough. I don’t understand this complaint at all.  How is Twitter more real-time than either sitting at your desk with your email client open, or checking your BlackBerry for new messages?  Yes, Google Wave lets you see people type in real-time, but do we really need that?
2. Email is not dynamic enough. I don’t want email to be dynamic.  Email is a way to communicate static thoughts.  Tools like Google Docs, Dropbox, and Versionshelf are there for collaboration.  But email is a linear record of events and discussions, which is essential if we want to preserve any kind of sanity in business communication.
3. Email is chronological, not relevant. This complaint perplexes me the most.  If email isn’t relevant, you may want to write different emails, or just spend a little time setting up a few filters to get rid of Hilton HHonors statements and other useless newsletters.  Chronology brings order.  Even though the most important things might not be at the top of your inbox,  timestamp is an important element in helping us separate the urgent from the important.
4. Email reduces productivity. More than being on Twitter all day reduces productivity?  I’d like to see how productive people are who do business in 140 characters.

In short, I’m just not ready to give up email.  It serves as a very effective To Do list for me.  It allows for accurate and extensive documentation when needed, as well as quick decision-making with a variety of stakeholders.  Long live email.

Introduction

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.

A universal model for software product development - first draft

So, here is what I have come up with so far.  I hope that this initial attempt at a universal model for software product development can generate some discussion on what works and what doesn’t, what’s missing, how it can be refined, etc.  Below the illustration I go into more detail on each aspect of the model (click to enlarge).

There are a few assumptions that are important to note about this model:

• Regardless of the development methodology, representatives from Product, Marketing, Business, Design, and Engineering should be involved to some extent in each step, all the way to the writing of the technical specifications, after which it largely becomes an Engineering and Product effort.
• Having said that, it is important for one person to own this process (i.e. be accountable for its success) from start to finish, and that person should be the Product Manager.  A good product manager is not a dictator.  He/she is a facilitator between all the different stakeholders in a product, and the really good ones are able to get through this model on time and on budget, every time and with as much consensus between groups as possible.
• This model is designed to work for any organizational structure, project size, and timeline.  If the project is large, more time can be spent on each step.  If the project has a tight timeline, it doesn’t mean that you will skip the “Iterate” part of “Design + Iterate.”  It just means that you will spend less time on it (more on that later).
• I highly recommend reading Adam Nash’s post entitled “Guide to Product Planning: Three Feature Buckets.”  He recommends that every feature release should have a combination of what he calls Customer requests, Metrics movers, and Customer delight.  I am in total agreement with him, and this is an important underlying assumption for this model to work effectively.

Detailed discussion of the different aspects of the model

Let me start by saying it is possible to write a separate blog post about each of the bullet points below.  My goal here is to be general and make one or two points about each aspect.  If there is interest I could expand further on any of the concepts in the model.  So with that said, let’s look at some definitions and implications of the model:

• The starting point - identifying needs.  At the beginning of any project (new or iterative), it is important to gather and synthesize input from three different sources:
  • User needs.  Everyone needs to have a good understand of the market, the target segments, and their behaviors and attitudes.  There’s not enough room to go into detail here, but it is important to look at four sources of user input: market research (segmentation, etc.), user experience research (usability studies, ethnographic explorations), site analytics (behavioral analysis), and customer support (call transcripts, interviews of CS reps, etc.).  Having this common understanding allows the organization to build products that matter to users.
  • Business needs.  User experience practitioners too often neglect the fact that well, your site has to make money!  Revenue goals are not a good excuse for bad design, and that attainable revenue goals are essential to push the organization to design good product.
  • Technology needs.  Engineering needs to be at the table from the start.  They know the limitations of the product, they know what needs to be fixed, they know where the architecture can improve.  Their up-front input is essential in good product development.
• Problem statement (Requirements).  I am indebted to Pragmatic Marketing, particularly a post entitled “On Reqs and Specs: The Roles and Behaviors for Effective Product Definition,” for the definitions I use for the three different documentation outcomes in this model: Requirements, Functional specifications, and Technical specifications.  The first outcome from the discussion and synthesis of needs is a common understanding of the problem statement you are trying to address, which takes the form of Requirements.   A requirement is simply a short statement of the problem, and Pragmatic Marketing recommends the following format:  “Our preference is the Requirements That Work format: [Persona] has [problem] with [frequency]. It forces product managers to explore the problem, not the solution, and helps the design team understand the context of the problem.”
• Diverging and converging design thinking. Once the problem has been defined and agreed upon, the team starts thinking about solutions.  There are three important aspects of this phase, which is often called Product Discovery:
  • Start with blue sky ideation (divergent thinking).  At this point, don’t limit solutions by what is technically or otherwise feasible.  Spend time dreaming about the product - this is where innovation happens!
  • Relentlessly prioritize (convergent thinking).  This is the part of the process where nonsensical ideas are thrown out, and the team consolidates around a few possible solutions to the problem that can be further explored.  Remember: there is no commitment to implementation or specific designs yet at this phase.
  • Apply the technology filter only after the ideation phase. I wanted to explicitly call out the roll of Engineering during the solution discovery phase.  It is a mistake to bring Engineering in too late in the process.  There is a very important technology filter that needs to be applied during prioritization.  What is technically feasible?  If something is currently not feasible, what would it cost to build the right architecture?  Those early inputs can save a lot of headache down the road.
• Functional specifications. The second output document from this model are the Functional specifications, which Joel Spolsky defines as follows: “A functional specification describes how a product will work entirely from the user’s perspective. It doesn’t care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.” Note that we’re not talking about technical implementation yet, that comes later.
• Design and Iterate.  Everyone designs a product, but it is sad to see that when time/budget gets tight, iterating on it before it goes live is often the first part of the process to fly out the window.  It cannot be overstated how important it is to prototype and test your designs before they go live.  And not having time is really no excuse.  If you have no time, make a paper prototype and test it with three of your friends over coffee in the evening.  You’d be surprised how much value this can add.  Boxes and Arrows has a great article on prototyping and how to integrate it with your design process that’s well worth the read.
• Technical specifications. Only once you have a set of Functional specifications and a Prototype of some form (even if it is very low fidelity), it is time to work on implementation.  Quoting Joel Spolsky again, “A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.”
• Build and launch. If you’ve done the upfront work, this could actually be the easy part.  You have a set of requirements, a prototype, and a detailed set of specifications to work with, so now it’s time for the Engineers to work their magic and build the product.
• Assess.  The assessment phase is extremely important and often overlooked.  It is important to define your measures of success upfront, and then follow up to see if you’ve met those goals.  How do users respond to the product?  Are we meeting revenue/engagement goals?  Are there bugs that need to be fixed?  What can we learn from how users interact with the product to give us ideas for new products?  I’m also an advocate for using the same four sources of input we discussed earlier (market research, user experience research, site analytics, and customer support), as opposed to relying on only one methodology, like a 3-week A/B test.  More on the dangers of that in one of my earlier posts.

Implications and final thoughts

I think this is a decent first attempt at a universal model for product development that can be applied to any timeline or organization type, but it is far from perfect.  I hope that the product management community can come together and refine this so that we can end up with a credible, relevant, and useful model for building great product.

Eventually, I’d like us to build out this model so that it is more easily adjustable based on certain constraints that might exisit within a project, such as budget, time, development methodology, and team size.  But let’s see if this one passes the smell test first…

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:

Notice that there are (or appears to be) four editable form fields on this screen:

1. The Safari address bar
2. The Safari Google search bar
3. The small MSN search box
4. The big Bing search box

There should be little confusion with the first two fields — they are part of the Safari browser and clearly not part of the mobile web content.  However, the other two search bars present several problems.  Notice how both have the little magnifying glass search icon, indicating that you should be able to use both to search.  The questions users will ask themselves are, which search box should I use?  Do I want to search MSN or Bing?  What’s the difference between these two search boxes?

I’m sure most of you have also figured out what’s actually going on here — the Bing search box is not a search box at all, it is a clickable advertisement (pre-filled with “Miley Cyrus” for some reason, but let’s leave that out of the discussion for now).  It’s also clear from what we know about affordance that the user is encouraged to use the Bing search box due to its prominence, size, and iconography that’s consistent with search behavior across the web.  I think we can all agree that this is just bad usability, plain and simple, but I also started thinking about how something like this could happen.  I can think of two scenarios:

• Informational content and advertising are owned by different groups. It is very likely that the advertising team were given the top banner placement on this page, with not much oversight about what they put in there.  They likely have their own designers who design for the advertising team, with no need or desire to think about the context of the entire page.
• Revenue goals trump good usability.  Another possibility is that the designers are fully aware of this issue, but that Bing, possibly a different business unit than MSN Mobile, has strong revenue goals that they have to meet for their advertising campaigns.

Or it could, of course, be a combination of these two scenarios.  I think we can learn some very important design lessons from this seemingly innocuous usability flaw:

• Never design in isolation.  This is such a simple principle, but it is still so remarkably easy to guess a company’s organizational structure just by looking at their web site.  Siloed design is one of the easiest design problems to fix, but it does take some courage: strong product management, a sincere desire to collaborate across business units, and an executive mandate to make it happen. All the MSN team had to do was get the designers/PMs together and design a Bing ad that fits with the page structure and doesn’t cannibalize search queries that should go through the MSN search box.
• Aggressive revenue goals are not an excuse for bad design. As a user experience product manager, I am a realist and completely in favor of feature prioritization and pushing for meeting aggressive revenue goals.  But revenue-generating features should never be implemented at the expense of the usability of your web site. Too often we see examples of poor implementation of an interface because the team couldn’t find a way to reconcile the business goals with proper user-centered design.  I believe the MSN Mobile example is such an occasion.

But wait, there’s more!  Unfortunately, the MSN Mobile example then goes from bad to worse.  Clicking anywhere in the Bing ad brings up this page:

There’s just not much you can say about that.  At this point you’ve lost customers who could have done their searches through MSN Mobile.  Game over, everybody loses…