Author: will

A good scrum sprint demo

Posted on by will

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!

Seek understanding – not insurance

Posted on by will

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.

Be delightful

Posted on by will

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?

What makes a good Product Manager?

Posted on by will

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

Recipe for a good SEO strategy: content worth linking to

Posted on by will

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

Posted on by will

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

Posted on by will

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?

Chasing rabbits

Posted on by will

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.

The Lexus Response

Posted on by will

In 1989 Toyota launched a brand new series of luxury cars designed to compete with the likes of Mercedes Benz and BMW. After 9 years and over a billion dollars in investment, the first Lexus vehicle, the LS 400, was launched. Three months later, two owners contacted Lexus to complain about an overheated brake light.

Lexus’s response was quick and decisive. They launched a voluntary recall of every single vehicle sold to date (over 8,000). They sent technicians to pick up, repair and return cars completely free of charge. They even flew in technicians to customers who lived in remote areas and rented garage space nearby to conduct the repairs, to minimise the amount of inconvenience to the customer.

The cost of the recall probably came close to the entire profit from all sales, if not more. I’m sure other car manufacturers were chuckling as they saw Lexus throwing away so much money. But the result? 8,000 very impressed and happy Lexus owners, and an astonished market. It was this move that gave the Lexus brand the image of quality and care which it still carries today.

This is a great example of how you can turn a potential quality problem into a perception of good quality.

At a previous company we modeled our customer support strategy on this. We called it ‘The Lexus Response’, and the strategy was basically to overwhelm customers with helpful, timely and empathetic support so that they had no choice but to feel supported and looked after.

You can turn a frustrated customer into an extremely delighted customer by how you respond to their problems or concerns. This often leads to customers who have experienced quality issues with your product having a better overall perception of product quality than customers who have experienced no quality issues, just like the 8,000 Lexus LS 400 owners.

In a recent post, Cindy Alvarez has some good points about how to respond to customers, which ties in will with the Lexus Response. She says when customers take the time to complain to you, respond with the 4 A’s:

  1. Apologise
  2. Admit
  3. Ask
  4. Appreciate

If a customer or user of your product is passionate enough to take time out to give you feedback, good or bad, then consider the Lexus Response.

Quality is boring

Posted on by will

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.