Software’s worst enemy: consensus

A vote for everybody is a vote for nobody.

A committee (parliament) voting on something

Photo from here.

The best software and products dazzle out of the box. They set new boundaries and exceed expectations. And they don’t settle for less than outstanding.

Designing software with lots of stakeholders is complicated, but when the product manager prioritises reaching a compromise between all the stakeholders instead of pushing for unique, beautiful and remarkable, the result is more often than not unspectacular.

Worse still are product teams that are set up without a clear product leader – product teams comprised of a group of ‘area’ product managers, who are each responsible for their own product piece, but who together, and in a purely democratic way, are supposed to come up with one aligned, cohesive and most of all compelling end-to-end product proposition. This is called ‘design by committee’, and nearly always ends in mediocrity.

The problem here is that each area product owner is focussed on his or her piece of the overall proposition, and each have their own priorities, visions and strategies. Just packing these guys together in a room is not going to result in them coming up with a remarkable and balanced product proposition. What this scenario often results in is some kind of portal; it’s at best a mash-up of separate products – something that tries to do everything and ends up doing nothing particularly well.

A product needs a product leader – someone who is willing to make decisions that displease some people and to fight for the ultimate product vision. Michael Arrington, founder of Techcrunch, says:

“Product should be a dictatorship. Not consensus driven. There are casualties. Hurt feelings. Angry users. But all of those things are necessary if you’re going to create something unique.”

A product team should not be a democracy. A product team needs a leader; it needs someone who calls the shots and makes the decisions that will displease, disappoint and delight.

Consensus-driven teams often have challenges understanding and agreeing on what is important now (prioritisation) and what is important overall (scope). A product team made up of area POs have by definition conflicting objectives. The PO for component X believes that part is the key product proposition; the PO for component Y sees it differently. The result of the ensuing debate is often a compromise; “ok, let’s build it all”. In their fantastic book Getting Real, 37 Signals founders share their view on software design:

“Some people argue software should be agnostic. They say it’s arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible. We think that’s bullshit.”

Of course, there are important requirements that the ‘master’ Product Owner needs to fill. He or she needs to understand the product and be able to present a compelling vision. He or she needs to be able to make difficult decisions and disappoint some people, but be convincing and considerate in the explanation. Most of all, he or she needs to understand the product extremes that make the product unique and remarkable, and not compromise on them. In other words, they need to be a leader.

I’ve seen product teams try to fill this role with a Program Manager. It doesn’t work: a roadmap slide is not a product vision. I’ve seen product teams try to fill this role with a Requirements Manager. It doesn’t work: a requirements list, or even a product backlog, is not a product vision. I’ve seen product teams try to fill this role with senior managers who poke their heads in every so often. It doesn’t work: a day’s worth of rash, under-informed decision making does not substitute consistent and detailed thought.

A product needs a product leader. And if that’s you, then my tip is: don’t give in to consensus, and don’t settle! You will never please everyone… not all users, not all colleagues, not all bosses. So please, give up trying. Sometimes innovation comes from having the courage to disappoint people (and the wisdom to know when!).

The dinosaur might be the solution

What happens if you start building a castle and you end up with a dinosaur?
That’s ok – maybe in the end the dinosaur is the solution to your actual problem.

What happens if you build a castle, but it turns out you really needed a dinosaur? Well, then you’re in trouble.

With any creative endeavour, whether it’s a software project or something else entirely, build quickly just enough to solve your problem today. Start with the problem, break it down into smaller problems and prioritise them – then work on one problem at a time.

The thing with designing a whole castle is that it’s hard to know where to stop. How many turrets are enough? How thick should the walls be? How deep do we need the moat? Even if you can answer all of these questions today (and chances are, you can’t), the time you invest designing complex castle architecture could have been spent building the wall you really need to keep the attacking vikings out. Then during the years you spend building your mega-castle you are relatively unprotected, since the value of your castle comes when it’s complete.

Even if a whole castle is what you need now, chances are by the time you finish building the castle the world will have changed. How do you know you will still need a castle in 2 or 3 years? What if by then you need a dinosaur?

Solve today’s problem today, and save tomorrow’s problem for tomorrow. As counter-intuitive as it sounds, solving problems of the future today is very often not smart preparation, but waste.

Copywriting is interface design

Your product’s user interface is its window to the world. It’s how your users interact with you, and how you interact with your users. The words on your interface are central to the user experience, and crafting perfect copy is every bit ‘User Experience Design’ as designing the user flows, choosing colours and designing screen elements. Why, then, is copywriting so often left until the very end, done in a rush or, even worse, not really thought about at all?

Every word on the screen matters, as much as every button or every pixel. A great product can be made unusable if the copy is bad (or if the translation is bad, for that matter, but that’s the topic of a whole other post).

A few other things I’ve learned about copywriting from working on maps.ovi.com:

  • Hire a copywriter. A good one.
  • The copywriter should be a part of the design process. They should know the product design as well as the Product Manager or the UX designers. They should speak and breathe ‘web’ (or whatever product/industry).
  • There are different kinds of copy, and they each require a different approach and different skills. Product interface is different from product marketing copy, help copy, communications copy, social media posts, etc. It’s not necessarily the case that one person can’t write many different styles of copy, but you should know what kind you are writing.
  • It feels dumb even writing this, but here goes anyway: No spelling or grammar errors, please! Obvious spelling errors take a massive chunk out of your credibility. Yes, if you’re writing a blog it probably doesn’t matter so much, and the Internet is changing the way we write and communicate in the English language anyway, but still: would you think twice about giving your credit card details over to a site with a misspelling in the payments screen? I certainly would…
  • Don’t let non-native English speakers write the final English copy. I’m real sorry, but unless you’ve been living in an English-speaking country for 20 years, we can tell that it’s not your first language. That’s ok! But I wouldn’t trust myself to write the final German copy for my product either.
  • Don’t use technical jargon or internal codenames for things in your interface. For example, while we were working on bringing positioning to maps.ovi.com (the ability to see your own position on the map via your wifi) we called the feature ‘WiFi positioning’. Before long, the term WiFi positioning made it into our interface copy. The problem? A user would have no hope of knowing what WiFi means, what it does, etc. Keep technical jargon out of your interface.
  • Be consistent with yourself: if you call the button ‘Continue’ on this screen, don’t call it ‘Next’ or something else on the next screen. Users associate behaviours with patterns, and they learn to predict the functionality on new screens based on their experience with previous ones.
  • Be consistent with the industry: if every other product in your category calls a spade a spade, and you want to call it a shovel, you’d better have a good reason. Users also look for patterns across products and norms aid their learning curve. If you throw new terminology at new users, it makes it just that little bit harder to pick up and learn. A good example: think about the last time you installed a new program on your PC. Did you read any of the text during the installation process? Probably not, right? Because most installers follow the same process, have the buttons in the same place and so on, you know how it works and you don’t need to learn it each time. (Okay, now we’re talking more about interaction design, but you get my point…)
  • Be clear and concise: copy should be exactly as long as it needs to be, and not longer. Consider every sentence: can it be shorter without impacting the meaning or ease of understanding? If yes, then cut it.
  • Keep it to a minimum: it’s hard to read long chunks of text on the screen. In fact, most people will look at a long chunk and probably won’t read it at all. Keep lots of white space around your text to aid reading.
  • Talk about benefits, not features. “Syncronise your favourites with your phone!” Huh? Why do I want to do that? “Favourite places you add are kept in sync with your phone, so you can access them when you’re on the go!” Ahh, now I get it.
  • Consider Search Engines (SEO) where appropriate.

A good copywriting resource is Copyblogger.

Copywriting shouldn’t be an afterthought… build it in from day one.

Don’t be evil (product designers)

Today, for the first time in what seems like ages, my PC caught the flu. This time it was a particularly annoying piece of malware called HDD Low; one of those fake system config utilities that spams you with fake warnings about your hard drive or memory until you give in and buy their special ‘system optimiser’ software that removes the alerts.

I Googled for some assistance, and ended up on a website for a product called Trojan Killer. This site is clean and well laid out and free of advertising. It offers detailed information about the virus and some instructions on how to remove it. It offers two options: instructions to remove it manually, or a free trial version of their Trojan Killer software.

Let’s examine the scenario so far: a clean and modern looking website with no advertising builds trust in the site and in the company (normally ‘bad’ sites have lots of ads and just look unprofessional). The transparency of offering manual removal steps as well as the software install further builds trust (they don’t need me to download their software, so I assume the software is ‘clean’.) I am now at the point where I trust them enough to download and install their software.

I downloaded and installed the free Trojan Killer app, and after a normal install process the app fired up and started an initial scan. After about 30 minutes of scanning it not surprisingly found our friend HDD Low and also a couple of other little things. It presented me a list of 10 or so infected files, with a big red button to ‘Clean infections’. I clicked it…

… and was hit with the credit card details page. SNAP! Now, after 45 minutes of trying to remove this virus, I have two choices: cough up and pay money to buy this app, or go back to the drawing board.

This is a very ‘good’ example of consciously evil product design. The flow from discovery to installation of the software is designed to build your trust with transparancy and professionalism to encourage you to download the ‘free trial’ version which is not really free at all. It tricks you into investing your time letting it scan your computer and then it makes you nervous about the viruses and ‘suspicious’ software it finds. But a solution is only one click away! The ‘remove’ button is even there, ready to be clicked – but first, you just need to enter your credit card details…

Their methodology is simple:

Trust + Nervousness + Time investment = (evil) sale

For me, at least, tricks like this don’t work: I trust this application and this company far less now, and I am far less inclined to hand my credit card details over to them – but I have to wonder how many people fall into this trap.

Treat your customers fairly. Don’t use false offers to trick them into downloading your software. Be honest about what your ‘free trial’ does: if it has the capability to scan the computer but not remove the errors, that’s fine, but tell the customer before they download it. Sure, you might make a few sales with scams like these; but how many of those sales are likely to grow into valuable, long-term relationships?

Being open and honest will always pay off in the long run.

(By the way, I managed to remove HDD Low without installing anything (else). Instructions are here.)

Analytics, data and product innovation

It’s important to understand what your users do, how they use your product… but remember: data never paints the whole picture. User research, user testing, usability studies, behavioural analysis, usage statistice: it’s all important – understanding and making sense of this data is crucial for your product’s development – but this data doesn’t exist in a vacuum, and it’s not enough to (alone) drive a product.

An example: The first iMac was released in 1998 and apart from looking really funny it was the first personal computer sold by default without a floppy disk drive. There wasn’t even a place to build one in… you had to buy an external one and connect it with a usb cable. It caused an uproar – analysts and journalists called them crazy – you can’t ship a computer without a floppy disk drive!

When was the last time you even saw a floppy disk?

If apple had have run a survey with all their customers before releasing the iMac and asked the question: “would you expect a new computer to have a floppy disk drive?”, I’ll bet most of their respondants would have said ‘yes’. But product and market innovation doesn’t happen through user surveys or focus groups, and it doesn’t happen through analytics… It comes from visionaries who challenge expectations.

I had a similar conversation with a colleague recently as we were discussing including a new feature in maps.ovi.com. A couple of days after the discussion he came back to me and said: “we checked the application logs and site analytics, and we see very few instances of user behaviour that indicates that people want that feature, so we conclude that it’s a not feature that people want.”

Well of course there are not many instances of this behaviour in the logs. If your product interface doesn’t support a particular functionality (that is, if you don’t tell your users about it), how should they know to try it? And if someone did think to try it, and it doesn’t work, how many times would they try before they gave up?

User analytics is extremely important for optimisation and product evolution, but don’t confuse optimisation with innovation. Innovation is something else. Innovation challenges the analytics; it challenges the market, it challenges expectations and it challenges users themselves.

Do you innovate or optimise? To be remarkable, I think you need to do both.

Be delightful

Every interaction with a customer is an opportunity to surprise and delight them.

Two great examples of this have stood out to me in the last week.

Amazon.com

I’m a shockingly frequent Amazon shopper. There are so many things that I used to go to the shopping centre for that I now order from the comfort of my couch. Normally the stuff I order turns up at my house without a hitch, but this week (admittedly for the first time ever), a package went missing.

It took me a while to find the right email address to write to, but I found a link under the support section for enquiries about missing deliveries. I wrote a careful email describing exactly what the problem was, and I took special care to explain that I had looked at the delivery tracker and the package was listed as “undeliverable”. After an instant auto-responder mail, two days later I got a canned response back that politely asked me to check the delivery tracker if I wanted to see the status of my delivery…

The point is, it was quite clear that the person dealing with my inquiry didn’t really take the time to read my email properly or understand my situation, or else they wouldn’t have asked me to check the delivery tracker again, when it was clear that I had already done so, and that was the reason I was contacting them in the first place.

WordPress.com

I had a bit of a silly blunder and purchased an upgrade from wordpress.com for the wrong blog. In wordpress you need to purchase upgrades for a particular blog you own, and somehow I bought it for the wrong one.

I emailed support and told them what happened, but I didn’t really expect much in the way of support. To my surprise, less than 30 minutes later I got a response from a real person, who told me he had simply switched the upgrade to the right blog, and that was that. Then he signed with his first name, which I thought was a nice, personal touch.

I was astounded, surprised – and absolutely delighted.

As a user, which of these two experiences am I likely to tell my friends about? Well, both of them actually…

Every interaction with a customer or user is an opportunity to delight them. You don’t get many opportunities… opportunities are difficult and expensive to get, and users are becoming increasingly more fickle and the number of other options is ever-increasing… so don’t you want to make the most of each and every opportunity you have?

Recipe for a good SEO strategy: content worth linking to

The beauty of Google’s search algorithm is that it lets you find what you’re looking for, and it gets better all the time. Because Google is one of the most important ways to ‘get found’ on the web, a whole industry has arisen around how to “beat” the Google search algorithm: Search Engine Optimisation (SEO).

SEO is all about how to get your webpage to the top of the list. The algorithm itself is, of course, a secret – but hundreds of self-proclaimed ‘experts’ believe they can reverse engineer it enough to understand what factors influence a page’s SEO ranking.

What a lot of SEO experts forget to tell you though is that the best way to get a high ranking in Google is to create content that people want. Sure, you can tweak things like the page title and the URL to make sure the right things get noticed first, but if you have content or a site that people don’t want to link to or don’t want to view, than no matter what SEO tricks you pull, you’re not going end up on Page 1 of a Google search result.

Instead of spending 70% of your time working on your SEO, try putting 70% of your effort into your content… because at the end of the day, that is where your traffic is going to come from.

Teamwork: The product manager and UX designer

A discussion came up today on one of Nokia’s internal social discussion forums about how Product Managers should interact with User Experience designers. I was shocked to read that quite often not only do the Product Manager and UX Designer not really work together, but they don’t get along well at all. This is, to me, a very bad omen for the product…

My view is that the product manager and UX designer/design team need to a) work together on the product design and development, and b) understand and respect each other’s skills and strengths.

The product design is at the end of the day a compromise between the ideal user flow/experience, what is possible in terms of technology (eg, is that flow possible on this device or in that web browser?), and what is possible in terms of schedule or budget (eg, can we build that with the resources and time we have available?).

The UX designer should be an expert at building delightful experiences within certain constraints. The development team should be experts at building lean and fast software. In this landscape, it is the role of the Product Manager to pull the pieces together, make priority calls and find the balance between what is ideal and what is possible. (Striking the right balance is an artform).

The UX designer is not a customer of the Product Owner, or vice versa. If the UX designer ever utters the words “the requirements are not clear”, then the UX designer has missed the point and misunderstood their role.

The lead UX designer for a product should be like the Product Manager’s right brain. They need to work question each other, to challenge each other, to push each other. But most of all, they need to work together to create the best product possible. This means they need to share the same vision and have the same ultimate product goal. Continue reading

5 product management lessons from the MacBook Air

The first MacBook Air was, while another impressive piece of industrial design from Apple, not a fantastic computer. It was positioned as a normal laptop replacement, with a pricepoint to match, but specification-wise it was somewhere in between a normal laptop and a netbook, without the real power for anything more than email, web browsing and word processing. The focus on small led to functional issues like not having enough usb ports, and it suffered from frequent heat problems.

But was the MacBook Air a failure? Absolutely not. With the second generation Air models Apple has taken everything they have learned from two years of MacBook Air sales and usage and redesigned the Air from the ground up into a smooth, fast, delightful experience.

So what can we learn from this?

  1. Apple released a product that pushed the boundaries of expectations and that was probably ahead of its time.
  2. Apple decided to focus on one thingsmall – but refused to approach ‘small’ in the way that other manufacturers did.
  3. Apple took risks with the MacBook Air – it was not only ahead of its time, but it was risky in terms of its positioning and price point (high end) and also its specifications: would people really buy an expensive computer that could not handle processor-intensive applications like photoshop and final cut, etc, and that doesn’t even have a DVD drive? And supplying only one usb port was challenging everything consumers expected from computers (more ports, more storage, more RAM, and so on…)
  4. Apple got an idea out, watched how it evolved, how it was used, and what their users said about it, and they used that information to build a better, more targeted version from the ground up. They didn’t let consumer expectations drive their product innovation, but they did listen and include valuable inputs from user feedback and user research into their product design.
  5. Apple allowed themselves to fail on their first MacBook Air launch, in order to learn and succeed later. The best winners know how to lose…

Remarkable products take risks, push the limits of what’s possible and challenge incumbent perceptions and expectations. Is your product remarkable? Are you?

Quality is boring

I’ve had an iPad for a few months now, but only recently I started using it to read eBooks. Although for me an electronic device will never replace the texture of paper and the smell of the freshly pressed ink, using the iPad to read books is a delightful experience. I enjoyed it from the first moment.

Where the iPad excels in general is in the delight factor. It’s not only functional, but it’s pleasurable, even fun to use. You want to interact with it. You want to touch it!

The kindle, for example, has two buttons – a back and a forward. What else do you need? What else can you do with a book other than turn the pages? iBooks for the iPad has these buttons, but you can also pick the page up with your finger and drag it to the other side. You see a quaint animation of the page flipping, complete with a rustling paper sound effect. Not only is it slower to turn the page with this method, it’s also more cumbersome, as you have to move your hand that is holding the iPad, move it to the screen and make the swiping motion that turns the page. A book reader certainly doesn’t need this. You can’t do it on the kindle. But there it is on iBooks.

Why? Because it’s delightful. Because it’s fun to do; because the act of using your hands connects you emotionally to the book as you subconsciously reminisce on using a real paper book; and it’s fun to show people. “Look, you can even flick the pages with your finger!”

This, to me, is the difference between quality and delight. Quality is making the product work – flawlessly. If the software solves your key use cases in a predictable, intuitive and consistent manner, then it’s quality software. But people don’t buy quality – they buy an experience. They buy delight. When you buy an iPad you don’t just buy the aluminium, glass and engineering – you buy the right to show your friends how the pages turn on iBooks. You buy the ability to interact with software in a new, exciting and emotional way.

Pure quality is boring – but delight sells.

Are you designing a delightful experience? Unless you are writing software for insurance underwriters, you probably should be.