product design

Act like a startup

I recently presented at the AOP Forum on secrets of product success.  Twenty minutes to get through sixty two slides was fun; part of me tells me I need to slow down, be more considered and reduce the messages I want to get across.  Another part of me just says meh!

I ended the presentation with the below takeaway slide that is worth replaying here.  I believe that product owners need to start thinking more like entrepreneurs and their seedling product ideas more like start ups.

Think big: Start with a big picture, a vision, where you want to get to. This should be unconstrained thinking, divergent thinking before converging on the specifics.

Start small: Easier said than done, but this is the getting to a minimum viable product.

Fail fast: Get stuff to market quickly, test with your consumers and be ready to fail. If you fail early you fail cheaply. Realise that you have customers, users who are already passionate advocates of your brand. Take them on the journey of development with you. You not assume that everything you need to take to your customers must be polished and perfect. Don’t underestimate the positivity than can be accrued by engaging users in the development process

Grow success: Do not see the end of the project as the end of road. Getting to a first release is only the first step. Successful product owners will be engaged in a virtuous cycle of continuous design and continuous delivery. They can come up with an idea, a new feature and get it in to production in hours, or days rather than months.

Letting go is the hardest thing

Tim Brown from IDEO gave the audience at his TED Talk a simple exercise. He asked the audience to draw a picture of the person sat next to them. He gave them a minute to do so. He then asked them to show their pictures. “Sorry” was the stock reaction as the sketches were revealed. They had an inhibition on showing their work. When it comes to creativity, as we move beyond childhood we take on board inhibitions and feel more uncomfortable sharing our creative efforts unless we perceive them to be ready or any good. Getting a visual designer to share her work in progress is a challenge. We fear what others will think if our “deliverable” is not ready, is not finished or polished. We fear setting expectations, we fear disappointing, we kill our creativity with fear.

So we are uncomfortable at letting others into our personal creative process. Now take this to the organisation, to the enterprise and creative genocide is abound. Like the Head of Digital who had 130 different stakeholders to socialise the Organisation’s new website designs with. Enter the HiPPO. The Highest Paid Person’s Point Of view. And with a few of those on board you get design by committee and design mediocrity. Or the client who refuses to engage with customers or end users in the early stages of the design process in fear of what they might think. A fear of setting expectations, a fear that their competitors might see what they are up to. Killing their creativity with fear.

Letting go is the hardest thing. But it can also pay great rewards.

On 27th October people coming out of arrivals at Heathrow airport were greeted by singers and dancers and general merriment. As an ad campaign for T-Mobile by Saatchi & Saatchi it was inspired, creative but not without risk. All the members of the public filmed had to sign a release form, agreeing to their being used in the ad. What if they didn’t? But they did. Whilst meticulously planned, the success of the ad is in the general public. T-Mobile got over any fear they may have had of the unknown and let go of the product to let the crowd create. It’s an uplifting piece, and successful too; their youTube page has had over 5.5 million views. And to the bottom line? The ad saw a 12% rise in sales the week after airing.

Is success best measured by tickboxes or delight?

Product owners get hung up on the features, a shopping list of requirements rather than considering what is actually important to their customers.

Imagine it is 2007, there is no Apple, you are a new entrant developing a product that will go head to head with Nokia’s flagship phone the N95. You are the product manager who is responsible for the success of the product. You are focused upon beating Nokia; you’ve made it your business to intimately know the N95, you can recite the list of features it has from memory. You have a meeting with your design team and they break the news. They tell you the spec they have come up with.

“Let me get this straight” you say. “You are telling me that the phone you are proposing we take to market will have no Card slot, no 3G, no Bluetooth (headset support only), no decent camera, no MMS, no video, no cut and paste, no secondary video camera, no radio, no GPS, no Java…”

“Yup” the team say.

How do you feel?

Ditch the feature list that you’ve fixated upon in your quest to beat your competitors flagship product?

Only the brave would avoid the tick box mentality and strive for feature parity as a minimum requirement. Would you really throw out 3G, GPS and a decent camera; the real innovations in the market place?

The first generation of iPhone was released in June 2007, three months after Nokia’s flagship handset the N95. On paper, when you compare the phone features side by side, it is a sorry looking list. As a product manager would you rather have the iPhone or the N95 on your resume?

Below and here [SlideShare] is the story in pictures.

The tyranny of nice

My first English lesson with Mrs Sullivan aged nine. She was one of those teachers you remember. An awesome teacher.

Nice” she told the class, “nice is a word you will not use”.

The word “nice” was forbidden in her classes. And woe betide anyone who described their weekend as nice, or their birthday present as nice (probably an Action Man or Scalextrix or if you were really lucky a Raleigh Chopper or Grifter).

It is a lesson I learned and kept close to my heart today:  Nice is mediocre, saccharine, inoffensive, meaningless, ordinary, without passion, expression or meaning. “Nice” is a faceless word. “Nice” is something that the left brain aspires to and the right brain shuns. Nice is an anathema to the artist, to the designer. Nice doesn’t provoke, it doesn’t inspire. Nice is instantly forgettable.

“Have a nice day”.

Shit NO! (this deserves swearing – see the passion that Mrs Sullivan infected in me; what a teacher!) That’s “have an ordinary day”. It’s not a differentiated day. I don’t want to just have a nice day. I want to have an awesome day, a magical day, a memorable day!!

And the same with experiences and products.

Disneyland isn’t nice; it’s memorable and magical (despite the fact that you spend most of your day there queuing). Do you think that Steve Jobs would be happy if someone called the iPhone ‘nice’?

Nice is for Microsoft. It is for engineers to aspire to. Nice is not art, nice is not design, elegance, simplicity or beauty. Nice is dull mediocrity.

And yet nice is something that corporate software doesn’t even begins to strive for. There’s no place for nice in software methodology. Think Scrum; nice is rarely even a nice to have (it’s gold plating). Tell me Scrum Masters, in your zeal to deliver “business value”, ship the “minimal viable product”, I bet you’d be happy with what you deliver being considered nice.  F@@k that. Your projects fester in a world of mediocrity,  in a quagmire of backlog; picking off stuff to do, focussed on features and functions rather than customers goals and a desire to delight.

Bring it on Mrs Sullivan. Nice has no place in the English Language. Bring it on, Agile + Experience Design. Nice has no place in software development.

Can you banish nice from your lexicon; go beyond nice and seek delight?

I don’t want to have a nice day, I want to have a memorable day.

I don’t want to have a nice product, I want to have an awesome product.

I don’t want to have a nice experience. I want to have a memorable experience.

…And if I’ve designed an experience and the only word you can use to describe it is ‘nice’ then I consider myself a failure.

The Dumbo ride at Disneyland; it delights, people will queue up for it, even though there is nothing special about the ride itself.  Carousel rides are nice enough but forgettable, the Dumbo ride is memorable and an experience to enjoy

Follow fast

I’ll pick on a random industry. Let’s say you are an airline. Part of your digital strategy includes a refresh to your website (maybe you were inspired by this presentation I did a while ago on digital for airlines!). You’ve built a business case and secured funding for the project.  First things first, you get a design agency in and set them to work.

Some sort of competitor analysis is performed that proabably includes features and functions that “we like”, (for example ‘the tactile sliders in We like!  And an iPhone-like coverflow, got to have one of those…)

The information architect takes these ideas away and starts building wireframes and the creative team produce designs that bring these wires to life.  The team come up with lots of new, innovative ideas.  This is after all a ‘refresh’, and ‘innovation’ was probably one of the words in the brief.  The creative is fresh and ‘of the moment’, the IA has developed some new interaction models that are unique and compelling.  The business is sold on a new, innovative way of interacting with their customers, something that no one else does and will blow all their competitors away.

I’ve been bouncing ideas around with Luke Barrett (and because he doesn’t blog, I’ll write them down for him) around this approach; specifically the value of innovation against ‘follow fast’.

Luke reminded me of a project we worked on together many years ago. Before we started designing webpages we did usability testing. We did usability testing of the competitors, and of sites that were getting a lot of press as ‘innovative’.  This was at a time that had just started and the client were talking about how cool an avatar would be on their site, just like boo. We put people in front of and watched them suffer. Clearly the avatar was an idea good on paper, terrible on execution.  So we killed it.  Not on our site.

We observed what worked and what didn’t on a multitude of sites with real users. Then, like magpies, we took what was good and worked. Nothing particularly innovative, (let other people do that), we took the best of what existed and delivered on that.

So back to our airline. How about a different approach where they start by usability testing their competitors. Ask participants to book tickets on competitor websites. Understand what interaction elements work, what don’t.

Those kayak sliders, cool for geeks (maybe), but how about the target audience that flies and buys online with you?  It may not be cutting edge design, but Does a drop down work better?

The coverflow may be cool on your iPhone, but how successful is it for people seeking a holiday?  A static list has worked for websites till now (and it wasn’t so long ago that horizontal scrolling was the Great Taboo), just because Apple do something that looks cool for a particular purpose on their products, doesn’t mean you have to follow by scrapping your navigation.

There are no prizies for (design) innovation (other than for some award that the design agency may covet). The only metric that counts is conversion rates and the ability of the website to deliver the business case. Leave others to do the crazy innovation stuff, let others go through the dip when they launch new features, make sure you have got the platform and expertise right and be ready to follow fast.

Are you prepared for the dip?

So you are refreshing or rebuilding your website.  You are introducing new functionality and features, and sweeping away the old. You’ve done usability testing of your new concepts and the results are positive.  Success awaits.   You go live.   And it doesn’t quite go as you expected.  You expect that the numbers and feedback will go on an upward trajectory from day one, but they don’t.  What you should have expected is the dip.

Illustration of the dip

In October 2009 Facebook redesigned the news feed.  Users were up in arms, groups were formed and noisy negative feedback was abound.  A couple of years back the BBC redesigned their newspage, “60% of commenters hated the BBC News redesign“.  Resistance to change is almost always inevitable,  especially if you have a vocal and loyal following, you can expect much dissent to be heard.  What is interesting is what happens next.  Hold your nerve and you will get over this initial dip.  We’ve seen a number of projects recently where this phenomenon occurred; numbers drop and negative feedback is loudly heard.  But this dip is ephemeral and to be expected.  The challenge is in planning for this and setting expectations accordingly.  Telling your CEO that the new design has resulted in a drop in conversion rate is going to be a painful conversation unless you have set her expectations that this is par for the course.

Going live in a beta can help avert the full impact of the dip.  You can iron out issues and prepare your most loyal people for the change, inviting them to feedback prior to the go-live.  Care must be taken with such an approach in the sample selection o participate in the beta.  If you invite people to ‘try out our new beta’, with the ability to switch back to the existing site, you are likely to get invalid results.  The ‘old’ version is always available and baling out is easy.  Maybe they take a look and drop out, returning to the old because they can.  Suddenly you find the conversion rates of your beta falling well below those of your main site.  Alternatively use A/B testing and filter a small sample to experience the new site.  That way you will get ‘real’ and representative data to make informed decisions against.  Finally, don’t assume that code-complete and go-live are the end of the project.  Once you are over the dip there will be changes that you can make to enhance the experience and drive greater numbers and better feedback.

Using stories to sell products

Dolls are girls stuff.   I don’t count Action Man (Which I had a few of as a youngster) dolls.  But being a Daddy of two girls, dolls start to be part of my world.  Wandering down Michigan avenue in Chicago on Saturday I stumbled across American Girl. Not only have they have elevated the doll beyond a product and into an experience, they have created an experience around the buying and owning of their dolls.  The product, the doll, is almost secondary to the narrative.  Every doll has a back story,  indeed they come with a paperback to describe this story.  Books build on this story, as do DVDs computer games as well as the dolls clothes, furniture and accessories all extending the product experience.

Wandering around the store I passed the doll hair salon (dolls sitting on doll-sized hairdressers chairs with their hair being plaited, braided, styled, blow dried…), the hospital (fixing broken dolls, returned to the owner wearing a hospital gown and discharge certificate), the historical doll museum (dolls representing children from different eras)… Walking into the American Girl I had no intention of spending any money there.  I ended up buying two dolls and clothes, I bought into the experience and took home to my girls not just presents from Daddy’s worldwide travels but also a story to tell.

Dolls are a product that it is (arguably) easy to create stories, narrative and experience around.  It is easy to provide this as a case study, but harder for a completely unrelated industry (such as financial services) to learn anything from it.  Harder, but not impossible.  Look at comparethemarket and the way they are building a story with Aleksandr around what is a pretty dull product.  As you develop a new product or application, can you build a narrative that supports the product?  Once you start telling a story, what new insights come to mind? How can you build an experience beyond the immediate product?

Are you managing expectations beyond the team?

There’s this idea called the Disconfirmation of expectations theory that states that having unrealistically high expectations from the adoption of a new IT application will result in lower levels of realised benefits.  Get customers excited about a new product and fail to deliver on it and you will have unsatisfied customers.  And unsatisfied customers are unlikely to use the product to its full advantage.

There is a risk with products developed using agile approaches that they fail to deliver on their initial promise.  The immediate stakeholders know that the product will evolve incrementally, but is this true of the broader audience? Are they aware of the intended regular heartbeat of delivery or are they expecting a fully featured product at the first release.  How are you managing expectations beyond the immediate product team?

Be wary of what you say early on.  Creating a vision is essential but be mindful of how this is communicated. Early demos, proof of concepts, prototypes, wireframes often show a vision of the end goal, several releases into the future.  Words are easily forgotten, explaining that this is an end goal vision is not enough, you must show a vision of what the cut-down product for the first release is and ensure it is appropriately communicated.

Expectations work both ways, it is easy for the business to tell IT their requirements and assume they will be developed in their entireity in one go.  Similarly it is easy for agile developers to expect the business to understand their incremental approach to delivery. The key to success is effective change management; identifying all stakeholders (both core and peripheral) and create a culture of agility that goes beyond the immediate project team.  In a large organisation that maintains more traditional approaches, agile projects must be supported by a well designed communication plan that builds the relationship between both IT and the business. Identify whose life will be touched by the product and develop a strategy for communicating to them.  This doesn’t mean “they can see what is going on on the project Wiki” this means someone taking responsilibity for listening, engaging and evangelising on the product, the project and its goals.

Thinking about value in terms of advantage and benefit

A product rarely sells itself.  What sells a product is the advantage it brings and the benefits it delivers to the customer.  It is the benefit of the product that sells rather than the product itself. What is the advantage of the requirement you are stating, and what is the benefit it will bring the customer?

Let’s start with a product.  Think broadband.  It’s dull.  Put 10MB in front of it and it is still dull.

Now think about the advantage that 10MB broadband brings.  The advantage is that it is fast.  Lightning fast.

Now think about the benefit which that advantage brings.  The benefit is that you can download an MP3 tune in seconds rather than minutes with your old dial up connection.  You are no longer selling broadband, but the experience that it brings.

Let’s consider IT requirements to be products.  A dull list, a thick document gathering dust. How do you prioritise one requirement over another?  What is more important?

Agile introduces ‘stories’ as the requirement product.  They are written in the format ‘As a <role>, I want <a feature>, so that <some benefit is achieved>’.  It is the ‘So that’ which is usually the hardest part to articulate, yet it is the most important part of the story.

Liz Keogh describes how prompted by Chris Matts her preferred narative reads:

In order to <achieve some value>
As a <role>
I want <some feature>.

Applying the marketing thinking to how the story will “achieve some value”, don’t just define that value in the advantage it will bring, rather also consider the benefit it will deliver to the user.  The two are different.  There maybe a business advantage to delivering some feature, but if the benefit to the end user can’t be articulated, it’s real value must be questioned.

Design vision

Don’t be fooled into thinking that you don’t need to do any design when you adopt Agile.  Agile development strives to deliver business value early and often, focusing on getting working software to market as soon as possible rather than dwelling in documentation and ‘analysis paralysis’.  But let’s be clear, “business value” and “working software” are not the same thing.  You can quite easily get something into production that fails to generate revenue, decrease costs or whatever other yardstick you use for ‘value’.  What differentiates the two of them is design.  I don’t mean big up front design that details all the features and provides a concrete spec, I mean a design vision that articulates what the product goals are and a roadmap for getting there.  And what is a design vision?  A short statement of intent is a good place to start, and soon after a user interface mocked up in pen and ink.  It is cheap and easy and helps bridge the path from idea to execution.

1 of 2