South African movie site Ster Kinekor just relaunched their web site to much fanfare. Much of the discussion I’ve seen on Twitter about the new site is about their decision to remain completely reliant on Flash. I agree with all the technology arguments against Flash, but I want to take a slightly different approach here and talk about Flash as an enabler of bad user experience.

You see, Flash is like the guy who keeps giving your alcoholic uncle a drink while the rest of the family is trying so hard to help him get sober. Every time he gets close to quitting he gets “one more drink” from somewhere and falls back into bad habits. And this is what Flash is to user experience.

Every time you might get close to following standard UI conventions or have a simple flow, Flash comes in to whisper sweet animatic nothings in your ear… “Just one more flyout,” it says. “Just one more hover state - come on, everybody’s doing it.” Designing a boring old button? “No man,” says Flash, “we can make this thing move and light up with Flash, wouldn’t that be cool?”

And before you know it, you have this:

In my view, most of the user experience issues with the old Ster Kinekor site have not been addressed in the redesign. For example:

• There is no visual hierarchy on the site. Everything is important, so nothing is important. I just don’t know where I’m supposed to click.
• Animations are intrusive and adds to the confusion.
• Standard UI conventions are ignored. Buttons don’t look like buttons, links don’t look like links (links are grey on the site…).
• Forms are non-standard and not easy to fill out. For example, the checkout flow uses skeuomorphic design to make the credit card look like a real card, but it’s just confusing. And you can’t copy and paste your card number from a different document.

There are more issues, but that’s not really what this post is about. This post is a call to cutt off Flash as a primary development technology on a web site, not just because it’s slow, difficult for SEO, doesn’t work on iOS, and all the other technical arguments against it.

We need to cut off Flash mostly because it makes it way too easy to design bad user experiences. The web is undeniably moving beyond Web 2.0 (whatever that was) and into an era where simple designs that put content first provide the best user experience. And Flash simply doesn’t fit that mold.

Perhaps the most succinct summary of Monday’s Apple WWDC keynote is this tweet by Dustin Curtis:

I understand the sentiment, and a lot of the post-keynote blog posts echoed this general statement. The most measured response, in my view, came from Marco Arment, the creator of Instapaper:

If Reading List gets widely adopted and millions of people start saving pages for later reading, a portion of those people will be interested in upgrading to a dedicated, deluxe app and service to serve their needs better. And they’ll quickly find Instapaper in the App Store.

I’m certainly not going to stop using Instapaper. I’m deeply invested in the service and can’t see myself moving to Safari any time soon. But that’s beside the point. Here’s the point.

I find it strange that people are freaking out about how Apple is going after successful apps and integrating them deeply into Lion and iOS. Here’s Rich Mulholland (well, censored a little bit):

For my part, I agree much more with Justin Williams when he says:

Some people grow frustrated by Apple continually making inroads in existing developer’s territory, but it comes with being a part of the platform. The key is to ensure your product lineup is diverse enough that you can survive taking the blow Apple may offer at the next keynote.

The Theory

And this is where we have to start talking about Sociology theory (No, don’t go away, this is going to be great!). One of the key concepts in Social Network Theory is Ronald Burt’s theory of ‘structural holes’. This theory aims to explain how competition works, and argues that networks provide two types of benefits: information benefits and control benefits.

• Information benefits refer to who knows about relevant information and how fast they find out about it. People with strong networks will generally know more about relevant subjects, and they will also know about it faster.
• Control benefits refer to the advantages of being an important player in a well-connected network. In a large network, central players have more bargaining power than other players, which also means that they can, to a large extent, control many of the information flows within the network.

Burt’s theory of structural holes aims to enhance these benefits to their full potential. A structural hole is “a separation between non-redundant contacts” (Burt, 1992). The holes between non-redundant contacts provide entrepreneurial opportunities that can enhance both the control benefits and the information benefits of networks.

To understand the role of structural holes in this regard, it is necessary to understand the concept of tertius gaudens. Taken from the work of George Simmel, the tertius gaudens is defined as “the third who benefits” (Simmel, 1923). It describes the person who benefits from the disunion of two others. For example, when two people want to buy the same product, the seller can play their bids against one another to get a higher price for the particular product.

Structural holes are the setting in which the tertius gaudens operates. An entrepreneur stepping into a structural hole at the right time will have the power and the control to negotiate the relationship between the two actors divided by the hole, most often by playing their demands against one another.

Apple’s Strategy

This is exactly what Apple is doing, and have been doing from the start when the first iPhone came out (maybe even before). They saw the structural hole between 3rd party developers and consumers, and walked right into it. Through the app store, they built an enormous network (information benefits) where they broker the relationship between developers and users (control benefits). By providing developers with a massive audience, they became “the third who benefits.”

I also don’t think they’ve been particularly secretive about this strategy, so it shouldn’t come as a surprise to developers that if they have a one-platform strategy, and that platform is iOS, they might get disintermediated at some point.

Which brings us back to Marco Arment and Instapaper, and why I don’t think he’s in trouble. Instapaper is an ecosystem that’s intimately part of my workflow. It’s integrated with Firefox, iPhone, iPad, Twitter, Google Reader, Flipboard, Zite, … the list goes on. I’m not going to switch away, because I don’t see Instapaper as an iOS app. I see it as a solution to my reading needs.

So should developers still make iOS apps? Of course. But it’s important to realize that the product shouldn’t be the app. The product should be the problem you solve for users, on multiple platforms and in a simple, integrated way. Those are the apps that will survive (and even thrive) despite any changes that occur on Apple or another platform.

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”.

These are my notes from Oliver Rippel’s talk at NetProphet 2011. Oliver is the CEO of MIH, a group company overseeing African and Middle East online properties like Mocality and kalahari.net.

The state of e-commerce in Africa

• As soon as e-commerce becomes more than 1% of retail sales, that’s when it becomes mainstream
• US not the most successful e-commerce market - Korea is, with 9% of retail sales online. US is at 4%
• E-commerce in Africa is still nascent:
  • Egypt - 22% Internet penetration, less than 0.01% online retail penetration
  • Nigeria - 29% Internet penetration, less than 0.01% online retail penetration
  • South Africa
    • 6 million Internet users, 12% penetration
    • 0.4% online retail penetration
    • 16.7% credit card penetration
    • 14 e-commerce sites in Top 100 SA sites

Positive e-commerce macro-indicators in Africa

• Big average projected real GDP growth
• There is a growing middle class of 320m Africans
• High mobile penetration (World average: 60%; South Africa: 92%)
• The promise of accessible and affordable broadband Internet is there

Lessons for building a winning e-commerce business in Africa

MIH’s focus is on the full e-commerce value chain The brands cover the whole purchase cycle: awareness, interest, decision, action, post sale, resale

• Embrace mobile
• Leverage offline
  • Go where the users are - online marketing on its own simply won’t work
  • Go to shopping malls and put up posters - whatever works
• Cash is king
  • 50m million banks accounts in Africa, 95% of transactions are cash-based
  • The only mobile payment system that is scaling is M-Pesa in Kenya: P2P payments
  • They are converting a cash economy into a digital economy, so that can now also be used for e-commerce
• Build trust
  • Open marketplace model is inadequate in low trust early stage environment - unlike eBay
  • Instead, MIH uses controlled marketplaces that reduce barriers for buyers by building a trusted brand

BlackBerry maker Research In Motion just cut their earnings guidance for Q1 2011, blaming slower sales. Even as the future of RIM looks bleak from a US perspective, you wouldn’t think so looking at the South African market. BlackBerries are simply everywhere. I’ve always wondered why BlackBerry has such a large portion of the SA smartphone market, and I can think of two four reasons:

1. Most BlackBerry contracts come with unlimited free data, which (to my knowledge) no other smartphone handset does at a reasonable cost.
2. When it comes to business users, it’s still the only phone trusted by corporate IT departments.
3. A capable smartphone at a reasonable price (although an influx of cheaper Android and Nokia phones might make this a moot point). (Thanks Steyn for pointing this one out in the comments)
4. The popularity and cost-effectiveness of BBM (although WhatsApp largely takes this away as a selling point). (Thanks Stafford for pointing this one out)

Now, here’s where it gets interesting. The latest earnings guidance cut clearly spells big trouble for RIM, and in a great blog post on Forbes, Eric Jackson lists 10 questions he would ask CEO Jim Balsillie based on that news, including the following:

Your bullish analysts used to say “yes, the US business is dying but International is going to keep growing.” You seemed to be saying last night that demand is drying up in Latin America too.  Does that mean the US was a sign of what is to come for your future International growth?

Now combine that with a recent IDC report that predicts Africa would become the first truly post-PC continent:

IDC estimates that in South Africa, 800,000 PCs were shipped in 2010 and the number is expected to decline by about four percent annually to reach 650,000 by 2015. Meanwhile, 1.3 million handsets were shipped in 2010 and that rate is expected to increase at a compound annual growth rate (CAGR) of nine percent to reach 2 million annually by 2015.

You have to ask yourself: how long can BlackBerry keep its apparent dominance in the smartphone market in South Africa? As mobile demand increases it appears that they will simply be unable to produce hardware that can keep up with consumers’ ever increasing smartphone requirements.

The “How Angry Birds would look on a BlackBerry” joke is funny, but there is certainly some truth behind the joke. As the line between work and life continues to blur, you don’t want a business phone that can also make calls. You want a personalised handset that can also be used for work. This is something RIM simply hasn’t figured out how to do, so they continue to double down on the “corporate security” angle. As Slate recently pointed out in a review of the PlayBook:

The incoherence, I think, is a sign of something deeper: Research in Motion doesn’t know what kind of company it wants to be. It made its fortune selling gadgets to chief information officers””IT guys who wanted to give their employees access to office e-mail on the go, but only in a way that accorded with corporate security policies. When they talk about RIM’s strengths, the company’s leaders like to point to their “CIO friendliness.”

The trouble is, being friendly with CIOs doesn’t matter as much as it used to. Nowadays people don’t ask the tech guy which mobile gadgets pass muster. Instead, tech guys look to employees to decide which gadgets to support. RIM’s strategy””to infiltrate companies as a first step to becoming a mass-market hit””has been eclipsed by the Apple approach, which is to infiltrate schools and homes, and then hope that regular people nag their IT guys to let them use iPads at work, too.

Meanwhile, Nokia appears to have given up on the US, but they’re coming for Africa in full force:

Nokia is already working with developers in several African countries and Peng feels that Nokia’s next big growth opportunity is to go beyond bringing affordable voice and SMS to delivering affordable web and applications.

“Rural populations live their lives largely outside of the reach of high quality services; through solutions like Nokia Data Gathering, we are already supporting field workers to collect, send and receive information quickly and securely via a mobile phone helping circumvent infrastructural challenges and speed up data collections needs in sectors such as health, agriculture, environmental conservation, population census and emergency services,” added Peng, in a press release sent after her speech.

It might not happen in the next few months, but I think there is a dangerous trend on the horizon for RIM. Between mobile handset growth in SA, trouble in the US market, and huge competition on the way, there’s a perfect storm brewing in BlackBerry land.

[caption id=“attachment_1181” align=“alignright” width=“240” caption=“Thinking about writing at Melissa’s Food Shop, Cape Town.”][/caption]

How good I am at my job as a software Product Manager depends on my ability to do two things: Understand the needs that real people have when they go online (whether they can articulate it or not), and building products that satisfy those needs as well as meet business goals. It occurred to me this morning that in many ways writing is about doing the exact opposite. To a large extent, writing is about being selfish.

Virtually any book or article you read about writing gives the same advice: Write what you know and what you’re passionate about. Write what’s in you, not what you think people want to read. Just last week James Shelley reminded us that people cannot help but notice an individual with passion. In another post he says:

Although passion may at times appear dangerous, the planet does not need less human passion right now, it needs more passion than ever before ”” passion that refuses to be immunized by the lulling caress of consumption and the crippling inundation of knowledge.

But it is this apparent struggle between Design and Writing (with a big D and W) that makes it so damn difficult to write sometimes. As user experience designers we’re trained to get out of our own shoes and into those of others. It’s about their needs, not our likes and dislikes. “You are not the user,” we often say.

But I have a feeling that the best writers (and designers, for that matter) are those who are able to balance this apparent conflict between user needs and internal passion effortlessly. Writers and designers who truly astound us with their work are those whose understanding of what people need are so ingrained in their beings, so much part of them, that they’re able to express their passion in a way that meets those needs “without fuss or bother,” as the NN Group definition of User Experience states.

It is for this reason that I think if you’re in software, you should write. Anil Dash got me thinking about this when he said:

Some ideas are just bigger than 140 characters. In fact, most good ideas are. More importantly, our ideas often need to gain traction and meaning over time. Blog posts often age into something more substantial than they are at their conception, through the weight of time and perspective and response.

If nothing else, the practice of writing down your thoughts (yes, about the things you are passionate about) will teach you how to create words in a way that resonates with those who read it. And just go ahead and try to convince me that won’t make you a better designer.

The biggest problem is, of course, that we all hate our own work, especially in the beginning. As Ira Glass so eloquently puts it:

Nobody tells this to people who are beginners, I wish someone told me. All of us who do creative work, we get into it because we have good taste. But there is this gap. For the first couple years you make stuff, it’s just not that good. It’s trying to be good, it has potential, but it’s not. But your taste, the thing that got you into the game, is still killer. And your taste is why your work disappoints you. A lot of people never get past this phase, they quit.

He goes on to give this advice:

And if you are just starting out or you are still in this phase, you gotta know it’s normal and the most important thing you can do is do a lot of work. Put yourself on a deadline so that every week you will finish one story. It is only by going through a volume of work that you will close that gap, and your work will be as good as your ambitions.

If you’re noticing a change in this blog over the past few weeks, you’d be right. I’ve redesigned to put the focus on the content, and I hope to write just a bit more - even if that means fewer long-form posts. I have to test this theory that writing better words will help blur the lines between what I’m good at and what people need from software. We’ll see how it goes.

And you - yes, YOU. Go write something, ok?

I’ve been thinking a lot about the importance of humility in design. About a month ago David Gillis said the following in a great article for UX Magazine:

When it comes to designing experiences, cultivating a humble approach is absolutely essential. The sheer complexity of the design challenges we face demands open-mindedness - a willingness to test and modify assumptions, to make mistakes and be proven wrong.

Humility is about knowing what you don’t know, and when it comes to dynamic, interdependent, multi-platform systems, there are an awful lot of unknowns.

And then there’s this tweet by a good friend that’s been on my mind for a while now:

Ain’t that the truth.

But let’s also clarify: I’m talking about true humility here. Not the “Oh, I’m so humbled by your praise so let me retweet it to all my followers” humility. I’m talking about the humility that comes from realising that Design is about meeting user needs, that it’s a study of human behaviour so if any of us want to call ourselves experts at it we are sorely mistaken.

I didn’t think that a medieval monk could teach us much about design, but I recently stumbled on a quote by Thomas Kempis that brought this whole concept home for me:

A true understanding and humble estimate of oneself is the highest and most valuable of all lessons.

Should you see another person openly doing evil, or carrying out a wicked purpose, [or launch a really bad website,] do not on that account consider yourself better than him, for you cannot tell how long you will remain in a state of grace.

We are all frail; consider none more frail than yourself.

I don’t think this means we should stop being critical when we see bad design. But I do think it means we need to criticise with the aim to contribute to the design community, not break it down. If we learned anything from the Dustin Curtis “Dear American Airlines” story, it’s that we cannot possibly know why people make some of the design decisions they make.

So let’s help each other out, is all I’m saying. Because one day you might put a bad design out there, and all you’ll ask for then is a little advice and lots of grace.

Last week I delivered a new talk at a Cape Town SPIN meeting (the Software Process Improvement Network). While I was preparing for it I thought of a working title for my next talk:

A talk about preparing a presentation for a talk about preparing a presentation for a talk.

You see, I have a love/hate relationship with new talks. I love delivering a new talk, and I love getting feedback on what worked and what didn’t. I love making it better. And I hate pretty much every moment leading up to delivering it.

But this is, of course, the problem with the creative process.  It’s blood, sweat, and tears, most of the way. Rands recently wrote a post entitled A Hard Thing is Done by Figuring Out How to Start. He writes:

Those who do not understand creativity think it has a well-defined and measurable on/off switch, when in reality it’s a walking dial with many labels. One label reads “Morose and apathetic” and another reads “Unexpectedly totally cranking it out”. This dial sports shy, mischievous feet - yes, feet - that allow it to simply walk away the moment you aren’t paying attention, and each time it walks away, it finds a new place to hide.

I’ve spent a good portion of my life wondering where that damned dial is hiding.

He goes on to explain how random moments of discovery and seemingly useless tangents are all part of the preparation process, and that we shouldn’t be so hard on ourselves when we’re struggling to get started. He closes with this:

W’re addicted to quick fixes, top ten lists, and four-hour work weeks, but the truth is - if it wasn’t hard, everyone would be doing it and a hard thing is never done by reading a list or a book or an article about doing it. A hard thing is done by figuring out how to start.

You’ve been spending a lot of time thinking the result is what matters. You have a bright and shiny goal in mind that is distracting you with its awesomeness. It is this allure of awesomeness that is the continued reason why you keep searching around your house looking for that mischievous walking dial.

My guarantee is that what is going to make this bright and shiny thing awesome isn’t finishing. It’s all the little, unexpected details you discover trying to start. It’s all the small pieces of unexplainable execution that will not only make it yours, but also continue to teach you how you get things done. And when you’re done, you’ll discover finishing, while cathartic, is just a good reason to go start something else.

I’ve absolutely found that to be true. My basic process for preparing a new talk is as follows:

• First, I spend weeks researching and saving articles to Delicious.
• Then I live in FreeMind for a few days, building the outline of the talk.
• I then proceed to tell myself I’m ready to roll, so I  spend another week or more getting all those thoughts onto slides.
• This is followed by several nights of bad sleep as I start seeing the holes in my thinking, and struggle to find the right words/pictures/length/style/order.
• And then, suddenly and without fail, about two nights before the talk, I hit Flow. That “mental state of operation in which a person in an activity is fully immersed in a feeling of energized focus, full involvement, and success in the process of the activity.” Things suddenly fit, I spend 10 minutes re-ordering slides and it suddenly all makes sense. From that point on, the process is an absolute joy.

Why is Flow so hard to find? Or is it meant to be hard to find, because the creative process requires struggle as its fuel?

Whatever the reason, Rands helped me relax a little bit and panic less during the beginning phases of the creative process. Because all those starts, stops, and anxiety eventually come together to collide in the ultimate high that happens when things just… flow.

We’ve received quite a few questions about why we changed kalahari.net from a fluid layout to a 960px fixed width layout. There are pros and cons to both approaches, and Smashing Magazine did a great job of explaining those trade-offs in Fixed vs. Fluid vs. Elastic Layout: What’s The Right One For You?

For me, the most important reason to use a fixed layout is that it allows you to have full control over the experience and what the user sees on the screen.

But since a picture is worth a thousand words, I guess you can sum up the problem with fluid layouts with a single screenshot:

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