One of the hardest parts of Agile development, but also one of the most powerful and rewarding, is figuring out how to make the process work for the team you’re part of.  Even though the guidelines are clear, there is simply no “one size fits all” approach when it comes to Agile.

We as Product Owners need to loosen up a little when it comes to pre-determined process, and work with our development teams to design an Agile process that works for everyone involved.  With this in mind, developer @darb and I evolved the following sprint guidelines for one of the applications we are responsible for here at Yola.

The ingredients of a good sprint

Every two weeks we sit down and discuss the next sprint, and we make sure the following ingredients are included:

• 1 x silly name. Darb is partial to automatic Linux-generated names like Thundering Tuatara.  I am partial to non-silly names like “Sprint 3”.  But he won this argument — it’s all a game of give-and-take.
• 1 x revenue-related. Every sprint has to include at least one bug fix, enhancement or feature that will improve our top-line revenue.  We are a business, after all, and this part is too often neglected by Product Owners.
• 1 x front-end maintenance. With every sprint we have to make an improvement that customers will notice.  This can be small visual tweaks to increase usability, or bigger overhauls of the interface based on customer feedback and analytics.
• 1 x back-end maintenance. Performance improvements and general back-end maintenance get put on the back burner way too easily - and as Product Owners we are often very guilty of deprioritizing maintenance because you can’t immediately see the effects of working on this.  But balance is extremely important, and paying down technical debt needs to be part of every sprint.
• 1 x error messaging/UX improvement. This is related to front-end maintenance but different in that these tickets aim to address user experience and usability improvements mainly through changes in the interaction, not necessarily the visual design.

It’s important to note that these buckets aren’t mutually exclusive, so some tickets will address more than one issue — and that’s even better.  This is also the minimum requirement, usually we try to get a good balance of all kinds of tickets into a sprint.

The recipe for a good sprint

In addition to these minimum requirements of what should go into each sprint, we put together the following guidelines:

- Leave time for ad hoc planning and work.  Other stuff will always come up.  Don’t let it make you miss your deadlines — leave room for it so that you have “planned outages” in your sprint work.

• Make sure there is a good mix of big and small size/complexity tickets.  Momentum is so important.  Seth Godin talks often about the importance of shipping often, and to do that, you have to bite off manageable chunks of work.  Make that small text edit that’s been on the backlog for months because it’s just too small to schedule.  And couple that with bigger tasks that get you closer to your overall product vision.
• Make effective use of priority. We use Jira to track our projects, and we use Priority to schedule the order of work.  We have to get P2 and P3 projects done in the sprint.  P4 and P5 projects are nice to have, and we do them if there is time.  For P1 work, see the first bullet…
• Stir Rian into vitriol. I’m not sure why it is important for Darb to find new ways to freak me out every week, but he seems to thrive on it, so this remains in the recipe for now.
• Simmer in QA by mid 2nd week.  It’s such a simple thing, but so many organizations forget that for something to release on Thursday, it doesn’t mean that first round development is completed by Thursday morning.  It means that at least some first round development needs to be completed by Tuesday morning so that QA can start.
• Rinse and repeat.  And then we do it all over again.

The “ingredients” and recipe are very specific to the application that Darb is the lead developer on, which is our payment system — with all its many back-end and front-end complexities.  Obviously different applications need different ingredients.  On our website, for example, we place a lot more focus on front-end than back-end.

And I think that’s the point I’m trying to make — that the best product development process is the one that Product and Engineering agrees on, and it never looks exactly the same across all applications.

Last night I attended my first Cape Town GeekDinner, and I have to say that I will definitely be back next time.  Good food, good wine (thanks Delheim!), great atmosphere and discussions, and a few 10-minute geeky talks sprinkled in between… yes, this is an idea I can get behind.

I also got to do a short talk on 5 things I’ve learned about website redesigns from being involved in various projects at eBay and Yola.com.  The slides are posted below.  As I mentioned in my talk — since you can’t say a whole lot in 10 minutes, I went with breadth over depth here.  There are obviously a lot more that goes into redesign projects (and yes, I know Content Strategy is about more than not using Lorem Ipsum in your designs…).  But these are a some things I’ve learned going through the process a few times:

The highs and horrors of website redesigns

View more presentations from Rian van der Merwe.

I am moving countries with my family in 3 weeks, so I have been doing a lot of account canceling over the past week or so.  For the most part, it’s a pretty smooth process.  But that changed when I encountered the labyrinth that is the Microsoft Billing department. Describing how I was eventually able to cancel my Xbox Live account would take way too long, so let me just focus on one part of the experience that is indicative of a company stuck in late 90s Information Architecture.

In order to get to my payment options for Xbox, I have to follow this sequence:

1. Go to www.xbox.xom
2. Click on “Marketplace” at the top (this automatically shows the “Xbox LIVE” link in the second tier navigation as selected)
3. Hover over “My account”
4. Click on “Manage payment options”

Here is the screen with the major areas called out:

There are a variety of issues with this navigation structure, including:

• No connection (visual or otherwise) between the three navigation tiers. There are non-navigation elements between the tiers, so there’s no way to know how they are related.
• No visual hierarchy.  What is the main navigation on the page, and what is sub-navigation?
• Inconsistent “selected” link states.  The top tier doesn’t even show you what’s selected.  The middle tier uses black links that turn white.  And the third tier uses the tab metaphor.

The thing is that fixing this navigation isn’t that difficult.  It will take some time, but it requires a simple user-centered design strategy similar to what you would use to design any IA:

1. Compile a site map of all the links and page names.
2. Get a content strategist to write/edit link names so that they are understandable to users, and in line with the brand voice.
3. Do a card sorting study to understand how users would group the site’s content and links together (adjust link names as necessary).
4. Get a UX designer/engineering pair-up to design a single 3-tiered navigation structure.

I don’t understand why Microsoft can’t do this.  But there is simply no excuse for it.  It’s not like there aren’t plenty of resources and design guidelines for site navigation.  Here are just a few:

• 5 Navigation Bar Best Practices
• Tabbed Navigation, and What Makes It Useful
• Navigation Menus: Trends and Examples
• 25 Examples of Creative Navigation
• 30 Creative Javascript Navigation Menu Examples

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.