I’m a little late to this article that made the rounds last week, but I finally read The inside story of how Microsoft killed its Courier tablet. It’s a bit scattered and sometimes hard to follow the narrative (probably because it was split into two pieces), but it’s still a very interesting story and worth reading. For one, if Microsoft found a way to keep J Allard around, things might have turned out differently for them. He seems like exactly the kind of person they needed to deliver real product innovation in the mobile computing space.

The most interesting part for me is how the article shines a light on the differences between Microsoft and Apple’s approaches to product development. Here’s Jay Green in the CNET article about the Courier tablet:

Courier’s death also offers a detailed look into Microsoft’s Darwinian approach to product development and the balancing act between protecting its old product franchises and creating new ones. The company, with 90,000 employees, has plenty of brilliant minds that can come up with revolutionary approaches to computing. But sometimes, their creativity is stalled by process, subsumed in other products, or even sacrificed to protect the company’s Windows and Office empires.

Microsoft has a fear of not doing anything that could cannibalize their cash cows (Windows and Office), even if that means they have to do things that don’t create value for users. It’s an organization that’s optimized for profit, not product. Contrast that with Apple’s approach:

Apple hasn’t optimized its organization to maximize profit. Instead, it has made the creation of value for customers its priority. When you do this, the fear of cannibalization or disruption of one’s self just melts away. In fact, when your mission is based around creating customer value, around creating great products, cannibalization and disruption aren’t “bad things” to be avoided. They’re things you actually strive for ”” because they let you improve the outcome for your customer.

Kyle Baxter adds the following perspective on an approach that places product before profit:

[N]ot only does focusing on the product make for better products, but it completely changes the corporate, business and organizational decisions you make, too. If you are focused on maximizing profit (in the short or long-term), you end up making choices that inhibit great products and great success at best, and destroy your ability to succeed at worst.

The Courier project should serve as a cautionary tale about what happens when the fear of losing profit gets in the way of developing a potentially great product. A product that could have resulted in a very different tablet landscape than the one we have today.

Peter Merholz describes Instapaper creator Marco Arment’s approach to design in Craft in Interaction and Service Design:

Instapaper shows the power of approaching experience design as a craft, as opposed to some kind of massive organizational process. Too often companies launch something and then move on to whatever’s next. Instapaper shows what happens when you go deeper and deeper and deeper into something. Unlike Microsoft or Adobe, who simply tack on features with every new release, Marco, instead, refines the design, honing it, polishing it, like his app is some jewel. I’d love to see companies approach service design the way Marco has. It would require a fundamental shift in how they work, but the results could be quite beautiful.

How often do you hear the words “We’ll get to that in Phase 2”? And how often do you actually get to do “Phase 2”? It’s a running joke in the software industry that calling something a “Phase 2 feature” is another way of saying it will never happen. There are just too many squirrel projects, too many Shiny Things that need to get done.

It doesn’t have to work like that, though. Small, dedicated teams who have autonomy and a clear decision maker can focus on one area of an experience for an extended period of time. This can work even in large organizations, but it requires trust and a long-term vision, both of which can be hard to find in big companies. It is the only way to bring craft and care to a design cycle that’s often treated too much like a conveyor belt.

I was privileged to speak at Tech4Africa 2011 about a topic that I care about a great deal: how our environments and the way we work impact the quality of the software we produce. The talk came out of a question I keep asking myself over and over: why, despite our best efforts, do we still too often produce low quality software? Here’s the talk summary:

Why do we see so many web applications with inferior user experiences? Why do UX designers often get stuck being asked to “make the design pop a little more,” with no room or incentive to innovate? Why do some web developers feel demotivated and unable to break out of doing things the way they’ve always been done?

In this talk I explore some of the main causes of ineffective software development, and discuss practical recommendations on how to improve team structures and development processes to build high quality software that users care about, want to use, and that therefore makes more money for the business.

I discuss how designers and developers can work better together, how to ensure everyone gets input into the roadmap without it becoming chaos, and how to make sure that the business benefits are clearly articulated and communicated.

So here are the slides from my talk - I hope you find it useful. If you’d like to read more about this topic, you can check out a two-part series of articles that I wrote for Smashing Magazine.

One of the principles of UI design that I always look out for is error prevention. Good design anticipates any errors that a user might make, and then makes it impossible to make those errors.

Apple’s new iCloud settings screen, shown below, is a case in point. It doesn’t allow you to check the box to sync your photo stream until you update iPhoto to the version that supports it. It would have been easy to forget about this detail. They could have allowed users to check the box anyway, and let photo stream syncing just not work until iPhoto is updated somewhere down the line.

This might sound obvious when you see it done right, but it’s not always easy to anticipate errors. Sticking with the Apple/iOS theme, let’s look at the Omnifocus iPhone app. The app now supports location reminders on iOS 5, which means that you can set it to remind you to do something when you arrive at or leave a specific location. I wanted to try it out, so I set up a reminder to go off when I leave work:

The problem is that the iPhone’s GPS location tracking system needs to be turned on for Omnifocus in order for this to work. I didn’t realize that I didn’t have it turned on for this particular app, so nothing happened. The reminder just didn’t go off. I only discovered my mistake later that evening when I played around with the settings some more.

Designing for error prevention would have prompted me to turn GPS location tracking on for the app before allowing me to add a location-based reminder.

Small details matter.

Dhanji Prasanna wrote a great article about his experiences on the Google Wave team, and the difficulties of working in large development teams. He brings a particularly interesting perspective to UI engineering:

To say we should have been better prepared or organized is to miss the point - large teams starting on a new project are inherently dysfunctional. One common consequence of all this chaos is that experienced engineers seclude themselves to their area of expertise. At a company like Google, this generally means infrastructure or backend architecture. A major externality of this is that fresh grads, and junior engineers are shunted to the UI layer. I have seen this happen time and again in a number of organizations, and it is a critical, unrecognized problem.

UI is hard.

You need the same mix of experienced talent working in the UI as you do with traditional “serious” stuff. This is where Apple is simply ahead of everyone else - taking design seriously is not about having a dictator fuss over seams and pixels. It’s about giving it the same consideration that you give any other critical part of the system.

I’ve experienced this first-hand, and I’ve also seen what happens when backend developers are forced to do UI work (which can happen for a variety of reasons). I’ve heard developers say that they don’t like to do UI work because “it’s not real programming”. They prefer to focus on the real stuff, not this fluffy CSS/JavaScript thing.

Whether or not their perception is accurate is only one part of the discussion. What I want to point out is this: If you make backend developers do front-end work that they’re not passionate about (or worse, work they find embarrassing to do), they’re not going to be motivated to expand their knowledge and do a good job. That’s unfair to everyone and disastrous for the product.

It’s essential to have dedicated UI engineers in an organization so that everyone can focus on the technologies that they’re obsessed with.

Jason Mesut made quite a few waves this week with his presentation Truth and Dare - Out of the echochamber into the fire. It’s definitely worth your time so I recommend you click through and read it before you continue here. Ther’s a lot to like and a lot to think about.

Jason explicitly asks for feedback and counter-arguments, so I do want to address one slide in particular, shown below:

Now, I might be putting the puzzle together wrongly here, but since these slides came out right after I published a two-part series on Smashing Magazine called “Breaking Down Silos”, I’m going to assume h’s talking about those articles. If my assumption is wrong this is going to be really awkward, but oh well.

So, let’s look at why Jason is calling this concept “naive”. I wasn’t at the presentation, so all I have to go on is his bullet points.

Organisations are complex

Of course organizations are complex, and if anyone tries to argue otherwise they’ve never worked in one. But I never said that this is simple:

There are no shortcuts to breaking down silos. You can’t fix the environment if the organization doesn’t understand the problem. You can’t improve the development process if the right environment doesn’t exist to enable healthy guidelines. You have to climb the pyramid brick by brick to the ultimate goal: better software through true collaboration.

I don’t propose “7 steps to a happier you” in the article. I propose a process of understanding the problems and unique needs of the organization, followed by a tailored solution that takes those unique needs into consideration.

People are better in small groups

I absolutely agree, and that’s why prioritization at an organizational level needs to take this into account and empower small teams to do the work without interference. Her’s what I said in the article:

[Once strategic priorities are set], projects would move to small dedicated teams, which would have complete ownership of the design and implementation. The product council sets the priorities, not the details of implementation”Š””“Šthose are up to the teams themselves.

I go on to talk about the importance of autonomy and the meaning people find in their work when they work in these small groups.

Change takes too long

I don’t understand the argument here, so maybe this is one of those “voice-over required” points. But if the argument is that change takes too long so we shouldn’t even try, I don’t buy it. Her’s how I end the article, again acknowledging how difficult it is:

Building collaborative environments is not easy, because change management is not easy. But the positive outcomes of doing this far outweigh the pain of making it happen. You’ll end up with happy, creative teams that feel a sense of ownership over what they’re building and a sense of pride in its quality.

I’d also like to point out that I wasn’t being academic in these articles. Everything I wrote is based on principles we’ve tried and applied in real life in the organizations where I’ve worked. There’s always room for improvement and growth, but this wasn’t a theoretical exercise.

I know this doesn’t matter that much in the bigger scheme of things, and I admit that the only reason I’m even writing about it is a slight irritation with the word “naive”. But if Jason is indeed referring to my article (again, this is going to be really awkward if he’s not) I at least wanted to clarify my viewpoint.

So there that is.

A couple of weeks ago our 2-year old daughter threw my wife’s phone in the swimming pool. The resulting journey through the Vodacom customer service labyrinth to replace the phone was frustrating, but it also gave me a new level of understanding and empathy for the immense challenges of providing customer service to hundreds of thousands of people.

This is an article about social media, customer support channels, and the principles every company should establish in their culture to serve their customers better. And (spoiler alert!) I do manage to get a new phone for my wife.

“Umm, So, Our Daughter Threw My Phone In The Pool”

What’s most surprising about getting a call about my wife’s phone suddenly finding itself at the bottom of our pool is how completely nonplussed I was about the whole thing. When you become a parent the kinds of things that upset you change significantly. I think I’ve discovered a pattern: if there is no blood involved, there’s really no reason to get upset. So after establishing that there was no blood involved, I proceeded to the next step - trying to replace the phone.

My wife had an LG Generic (or whatever it was called) on one of Vodacom’s cheapest plans, and the thing has been driving her nuts. She’s had her eye on my iPhone for a long time, so I decided to try to upgrade her. The problem is that I’m not eligible for an upgrade until the end of December. And that’s where this journey starts.

My first step was to walk into a Vodacom store to ask for assistance. This is pretty much the extent of the conversation that took place with the support representative:

Me: “Hi. My daughter threw my wife’s phone in the pool, so I’d like to get her an iPhone please.” Rep: “Your contract isn’t due for an upgrade until the end of December.” Me: “I understand that. I’m saying that my wife’s phone is now wet and doesn’t work any more, so I would like to give you more money by going onto a more expensive plan.” Rep: “It’s against policy to do an early upgrade. That’s why you should insure your phone.”

Imagine that conversation with a “Sucks to be you!” look on the representative’s face, and you’d have a really good idea of how it went down.

Having failed with the first point of contact, I took to Twitter:

The response was very quick, asking me to DM my number so that someone could call me. I sent my number, and a representative called me the next morning. I thought this was getting somewhere, and I was already starting to write this post in my head. My headline (“Social media works!”) needed some work, but it was going to be great.

But not so fast”¦ I told my story to the representative, who looked up the account and told me the same story: “Sorry, it’s against policy.” (At least this time someone was sorry about it). I threw out what would become my standard line throughout this process: “You realize I’m trying to give you more money, right?” But no luck. The conversation ended when the rep told me, “I will ask the upgrades department if there is anything we can do.” Translation: “You’ll never hear from us, ever again.”

After not hearing from the “upgrades department” I sent another DM, and got a call from another rep. Same story. Against policy. “You realize I’m trying to give you more money, right?” Sorry, against policy. I then took it to the next level and told the rep that I will be taking my business to MTN, convinced that this statement would trigger some script alarm somewhere and get me a free ticket to a ride up the “escalation path”. Not so much.

Rep: “Oh. Well that’s not good.” Me: “No, it’s not. Anything you want to do about that?” Rep: “Well, this is our policy. Can’t be changed.” Me: “You don’t want to tell someone that I’m about to take my business elsewhere?” Rep: “I’ll make a note in the system.”

At that point I gave up and decided to wait until I am eligible for an upgrade. That decision lasted about 3 days. I decided to give it one last shot, and tweeted Vodacom’s CEO:

And this is where the story gets boring, in a good way. Pieter Uys tweeted me back (in my first language, which means he looked at my profile and thought before responding). 4 hours later I got a call to say we can do the upgrade. End of story. No questions, no statements about policy. I can do the upgrade = happy customer + more money for Vodacom.

Your Call Is Not That Important To Us

Before moving on to the main point of this article I want to tell another quick story. I’ve been banking with ABSA all my life. I’ve also been unhappy with ABSA all my life, but that’s a story for another day. I recently mentioned ABSA on Twitter and linked to this post. The post got retweeted a few times, and then I got this:

That really interested me. Here is a bank (FNB) that monitors what people are saying about their competitors, and joins the conversation in relevant ways. Notice that he wasn’t pushy, he was merely getting in on the joke. I tweeted back:

I said this would be a short story, so I’ll just say this. One week later someone from FNB was sitting with me, filling out forms to transfer all my accounts from ABSA to FNB. They took care of the whole thing, I didn’t have to fill out a single form. All because of a tweet. And I’m pretty sure ABSA doesn’t even know (or care) that they lost another customer.

It’s All About The People

All customer support revolves around people, processes, and tools.

CRM and community tools like Salesforce, Get Satisfaction, and Twitter give support reps the means to communicate with customers. Processes set guidelines for what those interactions should be like. But all of that is useless unless the people doing the support understand and live out the culture of the organization. The ease of establishing that culture also depends a great deal on the support channel used.

Synchronous, 1:1 support like in-store interactions and phone support is expensive and extremely difficult to manage. Unless you’re Zappos and call yourself “a support company that happens to sell shoes”, most companies don’t have a deeply ingrained support culture. So it’s very hard to filter the right processes and culture through to the 1:1 support channels, since they are generally pretty far removed from “management”. They are therefore very rarely empowered to make decisions that might not follow policy, but would be the best thing for the customer (and the company).

I would argue that my early upgrade situation is a good example of this. That representative in the store should have been empowered to ignore policy and upgrade me on the spot. It’s not her fault that she’s not allowed to do that, it’s just the way it is.

On the other hand, asynchronous, 1:many support like live chat, online forums, and social media platforms are much cheaper, and I would argue also easier to manage from a support culture perspective. You’re able to set appropriate guidelines (more on that later), and in general the people who manage those channels have a much more direct path to different resolution scenarios (and therefore more decision-making power).

All this to say that I am not upset any more about my bad experiences in the store and initially on the phone. Because I recognize how incredibly difficult it is to nurture a true culture of customer-centric support. And to find that balance between empowering everyone in the company to break policy when they feel it’s needed, while still having enough process in place so you don’t give away control of your short-term and long-term business strategy.

I don’t have an immediate solution for this, but I want to write about it because I believe it’s a very real problem that a lot of companies are struggling with. Especially now that social media support channels are getting so much adoption.

Lessons In Customer Service

Even though I don’t have the perfect answer, I do want to spend a little time discussing some recommendations I have for better customer service, based on my recent experiences with FNB and Vodacom.

1. Understand what engagement really means

There is no substitute for authenticity. When Pick n Pay asks what I’m going to be doing today, it doesn’t feel like real engagement. Why would I want to tell a supermarket that? When Vodacom sends me the scripted answer “I heard about the problem you experienced”, that tells me they didn’t really take the time to think about the response when sending it (“Well, of course you heard about it, I sent you a tweet!”).

When FNB joins a conversation in a natural way, or when the CEO of Vodacom responds to me by name - that’s engagement. It’s such a simple rule: read, think, respond like a human.

2. Web governance is essential

Web governance “defines decision-making processes for the web, and sets policies and standards for web content, design, and technology””in a way that respects subject-matter expertise” (from Web Governance: Become An Agent of Change). Defining user-centered standards for every touch point with an organization is enormously important to those who want to succeed, and it’s not getting enough attention at all.

One part of web governance that needs more attention in particular is content strategy, which “plans for the creation, publication, and governance of useful, usable content” (see The Discipline of Content Strategy for more). Among other things it defines the tone and language and underlying principles for talking to customers. Every company should do this before they open their Twitter account or create a Facebook page. (Btw, if you’re in South Africa and need help with stuff like this, talk to Kerry-Anne)

How you talk to your customers makes a huge difference to their experience, and if you don’t define a strategy for it, your community will define you and you’ll have no control over it. That’s not a good place to be.

3. Empower support representatives

I want to come back to this. As mentioned earlier, I recognize how difficult it is to walk the line between empowerment and total loss of control. But I think there are ways to test this out as a strategy without giving the whole house away.

Start with one specific department, call center, or representative. Allow them to make some decisions based on what they feel is right for the customer and the company, and see what happens. If they break some rules/policy, ask them why they did it, and follow up with the customer to see how they felt about the exchange.

This kind of empowerment isn’t a binary switch for the whole organization. Start small, test, and see if it might be possible to build a culture that encourages doing The Right Thing.

All’s Well That Ends Well

My story had a happy ending. But I know there are an enormous amount of customer support stories that don’t end that way. The rise of cheaper, more efficient channels for customer support can make experiences better not just for customers who engage in those channels, but for everyone. We can take the lessons from the asynchronous channels and apply them to the 1:1 interactions.

Be authentic, get in on the joke, and break some rules every once in a while. Because they did that, FNB has a new customer and Vodacom didn’t lose one. I think that makes it worth it.

In this post I argue that we need to communicate the differences between the science and art of Visual Design better to help change the common perception by stakeholders and clients that user experience is purely subjective.

One of the most difficult aspects of visual design is finding the right science:art ratio to accomplish user goals. I’ve always subscribed to what Tim van Damme calls the mathematics of design. You start with the science:

If art is about talking and expressing yourself, interface design is about listening and disappearing into the background. You listen to the content and its context, and take it from there, one step at a time. Don’t worry about the looks, just start with the variables. 1 + 1 + 1 + ”¦ Baby steps, over and over again until what you have on your screen feels right.

And then you mix in art where appropriate:

But sometimes, even 1 + 1 is too much to handle, and you need to clear your head. This is where art comes into play, in the broadest meaning of the word: Paintings, illustrations, architecture, human beings, even nature is art. They won’t help you decide whether you should draw a 1 or 1.5 pixel highlight, but allow you to take a step back and just decide on what’s more suitable or pick one and move on.

Of course, this is not a serial process. Great designers are able to design within that delicate balance between science and art, and find the right ratio as they’re doing it. And even though it’s not easy, I do feel that most designers inherently get this - that visual design is science and art combined in different levels based on the needs of the user and the application.

What’s even harder is explaining this to stakeholders and clients in a convincing way. Over the past week I’ve seen so many comments about how “UX is subjective” and “standards always change” that it got me thinking about a possible solution to this problem. I haven’t figured it out, but I’d like to write down some initial thoughts for discussion.

The problem with Visual Design

I think as a UX community we’ve done a good job of splitting out the different elements of UX Design. Stakeholders and clients are slowly starting to understand the difference between Information Architecture, Content Strategy, Interaction Design, etc. And most people also now understand that those functions are not just gut feel or whatever is the trend of the day. We’ve done a decent job of showing the evidence behind the decisions we make - thanks in large part to the results of user experience research methods like ethnography and usability studies.

But Visual Design is the odd one out in this equation. It walks the line between science and art so tightly that most stakeholders and clients only see the art part. So they look at a design, make a gut call, and think that it’s all just whatever style the designer fancied on that particular day. Sure, some of it is our own fault, and many designs don’t have enough science at all. As Zeldman pointed out:

When Style is a fetish, sites confuse visitors, hurting users and the companies that paid for the sites. When designers don’t start by asking who will use the site, and what they will use it for, we get meaningless eye candy that gives beauty a bad name ”” at least, in some circles. Not enough designers are working in that vast middle ground between eye candy and hardcore usability where most of the web must be built.

We have to find a better way forward.

Breaking down the elements of Visual Design

So how do we fix this? One way is to provide a much clearer distinction between the different aspects of visual design. I’m not saying we should split the job title into two functions, I’m saying we should be more explicit about the goals and outcomes of visual design. And it needs to be simple, so it can’t be too detailed. I’m not 100% sure how to do that yet, but here is one suggestion:

• Hierarchy Design could refer to decisions made during the design process that sets the appropriate visual hierarchy based on the scientific principles of visual perception (such as contrast, grouping, balance, symmetry, etc.). See Designing for the Mind as an example.
• Aesthetic Design could refer to decisions made during the design process to help the design fit the brand promise and elicit an appropriate emotional response (such as choice of color, typography, button styling, etc.). See In Defense of Eye Candy for more.

Now, as I already mentioned, there is a lot of overlap between these activities, and you can’t have one kind of visual design without the other. But there has to be a way for us to talk to our stakeholders and clients about the visual layer of design that is not based on style preference but on “hardcore usability” as Zeldman puts it.

As we continue to grow and define the different elements of user experience I believe that Visual Design has the most baggage to overcome simply because of the history of web design and its initial focus on what’s pretty vs. what works. What works is not subjective, and we need to communicate that effectively to our stakeholders and clients. It’s not their fault for not “getting it”, it’s our fault for not explaining it properly. Let’s change that.

Over on the 37signals blog they just reposted an old article entitled Product roadmaps are dangerous. Jason Fried says the following:

Instead of the roadmap, just look out a few weeks at a time. Work on the next most important thing. What’s the point of a long list when you can’t work on everything at once anyway? Finish what’s important now and then figure out what’s important next. One step at a time.

It’s hard to disagree with a person (and a company) you have great admiration for, as I do for Jason and 37signals. But I do think it’s important to set the record straight on product roadmaps - particularly when it comes to large organizations. The post highlights two main concerns with product roadmaps:

• Product roadmaps assume you know what’s going to happen 6 - 18 months from now
• Product roadmaps set expectations, so you can’t change them (and if you do change them it becomes a worthless exercise)

So let’s look at each of these points in turn.

Product roadmaps assume you know the future

Jason writes:

When you let a product roadmap guide you you let the past drive the future. You’re saying “6 months ago I knew what 18 months from now would look like.” You’re saying “I’m not going to pay attention to now, I’m going to pay attention to then.” You’re saying “I should be working at the Psychic Friends Network.”

This is not what a product roadmap is, or what it’s supposed to do. The purpose of a product roadmap is to set forth a long-term vision for the business, and break that up into smaller, meaningful pieces of work, based on what you know now. It’s fallacy to believe that this is an unchangeable list of dates about where the business is headed. A product roadmap that doesn’t react to day-to-day changes in the market and within the company is a pretty dumb document.

At my organization we are very clear that the product roadmap is a flexible guideline that can (and must) change frequently as needed. But it gives the teams (and the management team) something to work towards. It’s a common vision, a sense of direction that’s more than just fluffy language - it’s concrete evidence that we’re headed somewhere good, and we know how to get there.

We can change direction as many times as we want. This doesn’t make it a useless exercise, it means that instead of starting fresh on a new “roadmap” every few weeks, you build on your past successes, don’t make the same mistakes twice, and keep making measurable progress since you can see where you came from.

Product roadmaps set the wrong expectations

Elsewhere in the post:

The other problem with roadmaps is the expectations game. People expect you to deliver what you say you will in 4, 5, 6 months. And what if you have a better idea? What if ther’s a shift in the market that you need to address? What if what you thought wasn’t what actually happened? Any change in the roadmap nullifies the roadmap. Then the map isn’t a map at all.

If you have this problem it doesn’t mean that product roadmaps are wrong, it means that you’re doing it wrong. As long as everyone in the organization buys into the fluid nature of the roadmap, you won’t have this problem. In our organization we do this mainly through the mechanism of what we call the Product Council (I was partial to Intergalactic Product Force, but for some reason that didn’t fly so well). Here’s how it works.

The Product Council is made up of the heads (VPs) of every department in the organization: Engineering, Marketing, Support, Category, etc. This body has a weekly meeting where we discuss the current product roadmap and priorities. We ask ourselves, Are we still working on the most important things? If something more important comes up, we prioritize it higher in the roadmap, and something else shifts down. If we’re happy with the direction, we do nothing. If a new opportunity arises we ask ourselves, Is this more important than what we’re working on right now? Or is this something we should work on next? If so, what moves down in the priority list?

From here, I communicate with my Product Team about any changes, and we discuss this to make sure no one missed anything. But then - and this is important - the Product Manager has complete autonomy and ownership over the implementation of the roadmap. The Product Council sets the priorities (with input from all parts of the organization), but the Product Managers work with their development teams (and others) to set the timeline, the implementation details, the design, everything.

There’s more to it, but in the interest of brevity I’ll stop there. This process has three main advantages:

• It gives the management team complete transparency into what the Product team is working on, and it allows for anyone to make the case for a change in priorities. Why this kind of transparency is so essential is a subject for a different blog post, but in short, it takes away a vast majority of the politics you see in many organizations, and it frees up the teams to do what they do best - execute.
• It prevents scope creep. Nothing can go on the roadmap without something else moving out or down. As anyone who ever worked at a large organization knows, this is an absolutely critical part of a successful development cycle.
• It gives the Product Manager and their teams what they need to be successful: direction and autonomy. As Jocelyn Glei says: “Give your team members what they need to thrive, and then get out of the way.”

Why product roadmaps are safe (and essential)

At a practical level I went through the exercise of figuring out how we could execute in my organization without a roadmap. And I just can’t see it. Changes to current pages/flows affect changes we’ll make down the line - I have to think about that.

If you’re serious about frequent incremental change as opposed to large redesign projects (as we are), you can’t live without a roadmap because you’ll have no idea how far you’ve gone, what you still need to do, and what’s more important than something else. And perhaps most dangerous of all, everyone in the organization will come to you and want all their projects done right now, and you’ll have no systemic method for dealing with that in a way that’s best for the business.

Andy Wagner summed up my feelings on this issue quite succinctly in a comment on the 37signals post:

[Product roadmaps are] an opportunity to dream about what the future might look like so that as you make your day-to-day responses to the customer, you can do so consistent with building the future state. It emphatically should not be anything to be slave to, it should be dynamic and notional, not static and specific.

Jason says, “The further you get from now, the less you know. And the less you know, the worse your decisions will be.” We agree on that. My argument is that without a roadmap you only see now. And if you only see now without seeing yesterday and tomorrow, you don’t see a whole lot. And “the less you know, the worse your decisions will be”.

About a week ago I had a discussion with a colleague in our development team about the new product development process we rolled out a few months ago. One of the words he used to describe the new process is fair.

It was a passing comment and I didn’t really think much of it at the time, but since then I keep going back to that conversation, and the importance of fairness in the product management profession.

Loads of articles have already been written about the characteristics of a good Product Manager (see the end of this post for links to some of them). They’re all fantastic, and I go back to them constantly when I’m in the hiring process or looking for personal development areas. But I’ve never been able to find the one characteristic that I think a PM simply cannot do without. I now think that fairness is that characteristic. Here’s why.

The role of fairness in effective product management

Let’s look at one definition of the word fair:

fair. adjective. free from favoritism or self-interest or bias or deception.

Free from favoritism

One of the fastest ways to become ineffective in a PM organisation is to start playing favorites with a particular internal group, product line, or user base. As soon as people sense that you are not looking at all ideas and input equally and fairly, a lack of trust inevitably follows. And without trust, you’ll have to work a lot harder (and longer) to bring people along for the ride on your roadmap.

Free from self-interest

If you start doing things purely with reasons like “because I want to” or “because I’m being measured by this metric,” that same lack of trust happens very quickly. You cannot be effective by nursing your own pet projects and ignoring all the other needs around you.

Free from bias

This often happens when PM’s get news they don’t want to hear — especially from the user research team. If something doesn’t test well, don’t make up reasons why you are right and the users are wrong. Do the right thing and realign the design.

One of the hardest skills for a PM to learn is to take their own emotions and feelings out of the equation when it comes to decision making. Yes, a lot of gut feel goes into a product vision, but that cannot be based on personal preferences or preconceived ideas.

Free from deception

This one seems obvious, but you see it often, especially when it comes to metrics and assessment. Don’t ignore/distort negative data or make a problem someone else’s fault. The PM’s job is to own a product — and this means owning its successes and its failures. You’ll gain trust and respect if you not only claim the successes, but also acknowledge the failures and commit to do it better next time.

The elements of fairness in product development

The PM role is often referred to as “the great diplomat,” and with good reason. It is our responsibility to balance a variety of needs from inside and outside the business, and somehow turn that into a roadmap that delivers business value as well as meets user needs. A focus on fairness accomplishes that goal:

• Fairness to users. Approach users with respect, openness and transparency. Understand their needs, and explain to them when you’re doing something that makes it more difficult for them to meet those needs. (Don’t be like Twitter and hide behind reasons like “consistent user experience.”)
• Fairness to the business. Do everything you can to understand the needs of marketing, merchandising, customer support, etc. Pull them into the planning process, be clear about how projects are prioritised, and help them adjust to that process so that they can define their project goals in the right way to get on the roadmap.
• Fairness to technology. Don’t force the development team to make the technology do things it’s not capable of doing. Understand the technical debt in the organisation, and work actively to make those improvements part of regular development cycles.

A lot of this comes naturally in good product managers, but we need to be conscious of it every day. Fairness is a table stakes characteristic for an effective product manager. If you do it right, the real work of building great product can begin. But if you don’t, you’re dead in the water, working with a team that has no reason to trust that you’re doing the right thing.

More characteristics of good product managers:

• Recruiting Product Managers
• The desirable characteristics of a Product Owner
• Owning an Agile Product