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!

(more…)

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. (more…)

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

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

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.

(more…)

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:

(more…)

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

(more…)

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.

(more…)

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.

(more…)

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. (more…)