William Gill

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.

In the world of Scrum the user stories are at the heart of everything that’s added to the software: it’s how you break down the product strategy and requirements into discreet, develop-able chunks. We build software for our users, so it makes sense that everything that’s added to or taken away from the software is expressed in terms of a user need.

The Scrum textbook recommends the following standard form for a user story:

– As a user, I want to do {thing} so that I {reason}.

The trick is to focus the story on what the user really wants, not how you plan to solve that need. You need to keep the solution out of the story.

A couple of examples:

“As a user, I want to see my favourite places in a list so that I can find the one I am looking for.”

What’s wrong with this story? It is not a story about a user need; it is a specification for a solution. Does a user really want to see their favourite places in a list? Or do they just want to see their favourites? Is a list the only way to solve this need?

How about: “As a user, I want to find the favourite place that I’m looking for, so I can see information about it.”

Another example:

“As a user, I want to see Public Transport lines on the map.”

Do they? Or do they want to know where Public Transport lines run? Is putting them on the map the only way to do that?

How about: “As a user, I want to understand where Public Transport stops are in my city, so I know where to go to get the next train.”

Why is it important to keep the solution out of the story?

The User story represents the problem that the user wants to solve, to which you and your team need to find a solution. The steps to finding a solution are understanding the problem, brainstorming/investigating possible solutions, possibly in conjunction with benchmarking of competitor products and user research, then selecting a solution and specifying how that solution will work. When the solution is already embedded in the story, you spring over the first two steps, which not only means that you’re not looking at the problem broadly enough, and you will potentially miss good, new or innovative ways to solve the problem, but you’ll have no data to justify that the solution you chose was better than any other.

Write stories that focus on needs, and save the solution for the specification.

The Sprint Demo is one of the most important meetings on the sprint calendar. So why are so many sprint demos so poor?

Firstly, why is the Sprint Demo so important? I think for several reasons:

• It makes the progress (or, where applicable, lack thereof) of the team transparent (to management, to other teams, to themselves…).
• It gives the team an opportunity to show what they have achieved and a forum to celebrate their accomplishments.
• Ticking things off a list is fun!

I’ve had to sit through many exceedingly poor sprint demos, most of which could have easily been far better. Here are a few points or tips that I think can help get the most out of a sprint demo.

• There should be an agenda. If you are demoing with multiple scrum teams at once, it should be clear in what order the teams are demoing. Each team should also have an agenda of which stories from the sprint backlog will be demoed.
• There should be a demo computer in the demo room with an agreed and consistent configuration which connected to a demo environment. What is not able to be demoed on the demo computer isn’t demoed – this means no demoing from the developer’s local computer or any other temporary test environments. (Note: the demo computer configuration should ideally match one of your key users.)
• The Product Owner should accept a story as done in the demo, or return it to development (ie, to the product backlog).
• The Product Owner should remember to provide a bit of background to each story as its being demoed – specifically, what the business value for the story is, what problem the story is solving, what benefit there will be, and so on.
• All issues discussed in the demo should be recorded and transferred to either the product backlog or to the bug tracking system. Some teams might like to appoint someone to be the meeting scribe, or the QA people may enter new defects raised directly into the bug system.
• Stories should have passed a certain agreed defintion of ‘done’ before they are eligible to be presented.
• Never cancel the demo. If the team has no stories to show, then display no stories at the demo – but never cancel it. Canceling the demo sets a bad signal to the team that demos aren’t important.
• There shouldn’t be any surprises in the demo, and teams should prepare adequately for the demo if they want it to be a good one.

The demo is the chance to shine and celebrate for you and your team… make it count!

When you communicate, you have two responsibilities:
1. communicate your message
2. ensure the message is understood

#1 is easy – but it is #2 that counts.

You can do #1 and forget or skip #2 – but you haven’t really communicated. Saying words out loud is not communication – it’s just making noise. Communication implies an understanding from both the initiator and receiver of the communication.

You can also do #1 in such a way to make sure that #2 doesn’t happen – that’s called covering your arse.

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?

I was thinking recently about the relationship between UX experts and Product Managers, which got me to thinking about what a good product manager is – especially in the world of web products.

I think a good product manager needs to understand the whole scope of his or her product. In the world of web or mobile software, this means he or she:

• is a technologist
• is a marketer
• is a strategist
• is an entrepreneur
• is a risk-taker
• is a visionary
• is a leader
• is a networker
• is a communicator
• is a presenter and speaker
• is a thought-leader
• is a product expert
• is a salesperson
• is fluent in web and mobile language and technology
• understands user experience/user interaction paradigms
• understands software development methodology and software development tools and processes

(Anyone have anything to add to the list? I’m sure it’s not complete…)

This list, incidentally, looks pretty similar to a list of attributes for a successful startup founder. Is this a surprise? Not really, considering that building a product is just like building a little business, and to be as successful as possible you need to run your product like you would a business.

For what it’s worth, a product manager is NOT (at least exclusively):

• a requirements manager
• a project manager (glorified or otherwise)
• a scrum master

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.

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

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 thing – small – 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?

If you chase two rabbits, both will escape.

You can’t run in two directions at once, and you have no way of controlling where the rabbits are going to run next. You can maybe influence the rabbits by setting up boundaries; you can maybe predict the rabbits by knowing the terrain, but you can never fully forsee how or where the rabbits will end up fleeing.

Many products fail or run into troubles when they try to do too much at once, try to grow in too many different directions or try to keep too many options open. Too many markets, too many users, too many options. Hedging your strategy is sometimes clever, but the problem is too much hedging and too many plan B’s not only increases your complexity overhead but creates noise and distraction – whether you’re prioritising user stories or defining corporate strategy.

The most successful startups and products in recent years do one thing, but do it really well. Twitter is the best micro-blogging platform. Foursquare lets you share your location with your friends. Evernote lets you take and organise notes. What are you good at? Where should you focus?

When you try to move forward with the most risk-averse strategy, you’ll end up moving nowhere. The project with the least likelihood of failure is probably the most likely to fail.