Google Buzz is really messing with my brain.  All my other social media activities fit nicely along the private-public continuum we all have to juggle.  But Buzz feels like an invasion of my personal space.  By infiltrating the most private of online communications (email), it’s also daring me to move that privacy line a little bit, and let people in on conversations that they really have no business in being a part of.  One of the few positive reviews I’ve read about Buzz so far is this tweet by my friend G-J:

Good point, but Tweetie for the iPhone already threads Twitter conversations, and I use Twitter lists to keep up with people in my closer network.  So I’m just not sure what to do with it, and that makes my brain hurt.

Privacy and the public persona

This issue, as well as the widely reported privacy gaps in Google Buzz, are just the latest in a growing conversation about privacy on the web.  Facebook’s recent updated privacy settings created quite a stir, and out of all the gazillion blog posts discussing it, none was more insightful than the brilliant Danah Boyd’s article Facebook’s move ain’t about changes in privacy norms.  It is a must-read for anyone interested in this topic.  In the article she says the following (my emphasis added):

There isn’t some radical shift in norms taking place. What’s changing is the opportunity to be public and the potential gain from doing so. Reality TV anyone? People are willing to put themselves out there when they can gain from it. But this doesn’t mean that everyone suddenly wants to be always in public. And it doesn’t mean that folks who live their lives in public don’t value privacy. The best way to maintain privacy as a public figure is to give folks the impression that everything about you is in public.

That last sentence really stuck with me.  It is so true.  Just because people divulge intimate details of their lives online, doesn’t mean everything they do is public.  Joshua Porter recently tweeted the following:

Ain’t that the truth…

But what if I want to maintain my privacy in public?

Another interesting story in this same vein — and a great example of the uncharted waters of online privacy — is that of designer Dustin Curtis.  I’ve been following his blog every since he blogged about the fascinating chain of events following his redesign of the American Airlines website.  That made him a bit of a celebrity in the world of web design, but it turned out to be nothing compared to what happened next.  On the day of the Apple iPad launch, he posted some very real-looking (but very fake) photos of the iPad.  It quickly sent the Internet into a frenzy and got him coverage on Mashable, TechCrunch and The Washington Post, among other places.

The next day he tweeted, simply:

Dustin Curtis: 1, Internet: 0.

Well played, sir.  Well played.  What’s interesting is what happened next, though.  He got a lot of attention from this stunt, and his Twitter follower count exploded.  He created an air of mystery leading a lot of people to wonder who he is.  It even led to a question on Quora with some amusing Chuck Norris-type answers: “Who is Dustin Curtis?”  The post on Quora prompted this tweet from him:

The answer is, of course, pretty straight-forward.  If you create a public and controversial persona, and in doing so amass over 13,000 followers on Twitter, people are going to want to find out more about you.  And, as a recent Times article pointed out:

When you make your private life public, when you seek attention in that broad a manner, you’re inviting not just the cool and the loving, but the angry and aggrieved.

And that is where online privacy get tricky.  We already talked about how public people value there privacy very much.  But at some point, people are going to assume that because you live a lot of your life in public, you have no need to be private, and won’t mind people digging around in your personal life (since there is no personal life any more).  But that’s clearly not the case, as Dustin points out in his tweet.

Facebook as theater

In a similar vein, I have to say that I have become increasingly uncomfortable with public conversations on Facebook.  And by that I mean girls who write “I miss you” on their boyfriends’ walls, people making coffee arrangements on each other’s walls, etc.  Once conversations that should be private are undertaken in a public forum, they become theater — meant for the onlookers more than the participants.  And that’s troubling.

Yes, there are legitimate cases (mostly for the sake humor) to have public conversations on Facebook.  But if you decide to write on someone’s wall and not send an email or a text, you are doing it so that other people can see it.  And that hurts the authenticity of the interaction.

So it’s not just that the lines between what is public and what is private are getting blurred.  It’s also that what is acceptable in the public realm is changing, as proven by those “I have to go to the bathroom” status updates I’m sure we all see occasionally in our news feeds.

Where do we go from here?

There are no universally agreed upon guidelines for what should be public and what should remain private online.  I’m pretty sure there will never be.  But I do believe that where that line is drawn should be a conscious decision by every person who goes online.  You can’t share every detail of your life online and then expect people to leave you alone.  You can’t go on Facebook, not change your privacy settings, and then complain if some of your photos leak out.  On the flipside, you can’t build a blog audience by writing articles that don’t expose your opinions in some way.

But wherever that line is drawn, it is extremely important that there is a point where your life stops being public.  The article Danger online: Perils of revealing every intimate moment puts it this way:

Concerns, though, are growing about the decline of the private self. Many people are questioning the wisdom particularly of blogs in which ordinary people write regular updates about their children and spouses, and they are asking whether we are surrendering our privacy too easily.

Or to put it another way, from another great article on the topic, Party On, but No Tweets:

We are fighting against this whole idea that everything people do has to be constantly chronicled. People think that every thought they have, every experience ”” if it is not captured it is lost.

When you let go of the pressure to chronicle, you are free to enjoy the moment for what it is, without the pressure of getting that picture up on Twitpic.

Don’t get me wrong — I think it is possible to build fantastic communities online by living public lives — both for business and personal purposes.  And I am definitely not going to stop blogging or shut down my Twitter account.  However, more and more I am finding myself agreeing with another sentence buried in that last article: There is something magical about a life less posted.

Something’s been bothering me about Twitter’s version of the Retweet.  A lot has been said about the pros and cons of the feature, but here’s my main problem with it:

You can’t easily see when you’ve been retweeted, and by who.

Twitter Retweets don’t show up in your stream as @ Mentions, so the only way to see when you’ve been retweeted, and by who, is by going to Twitter.com, clicking on “Retweets” in the right nav, and then clicking on the “Your tweets, retweeted” tab.  That’s just too many clicks.  Some iPhone apps like Echofon and Tweetie support the Twitter Retweet, but they don’t show you who retweeted you.

The problem with this is that it reduces Twitter’s sense of community.  I often like communicating with those who retweet me, and this takes away that ability (unless you go through a lot of work on Twitter.com).

There are, of course, other issues with the Twitter Retweet function, like:

• No ability to add your own comments (but this is what the “/via @” syntax is for, so that’s probably ok)
• Diluting the value of retweets because some people use Twitter’s Retweet feature, and others use the traditional “RT @” syntax
• Weird and confusing syntax when someone uses Twitter’s Retweet function to retweet a “RT @” tweet.
• Tweetdeck, Echofon, Tweetie… they all handle Twitter Retweets differently, so it makes for a confusing UI.  For example, if I want to unfollow someone who Retweeted something, I can’t do that from within the tweet-level functions in Tweetdeck.

This might sound like I’m nitpicking, but it’s not my intention.  I applaud Twitter’s initiative to embrace the Retweet function.  And I think ever since Doug Bowman joined the Twitter design team, they have made Twitter.com a lot more useful with some great features.

But I do think this Retweet thing isn’t quite working yet.  I think having Twitter Retweets show up in your @ Mentions would solve a big part of this issue.  So, Doug - can you make that happen please!?

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.