marc, Author at dancingmango - Marc McNeill

Are you building a potato or a Sensation?

Wednesday, 13 June, 2007
By: marc

The humble potato is not worth a lot. The farm gate price for a 150g spud is negligible. How do you add value? How do you turn a worthless Maris Piper into a valuable commodity?

Potato crisps (chips) are a great example of a low value product being turned into high value one.

But that’s the easy part. The real value add is further transforming the product without fundamentally changing it. Innovation through packaging and marketing, making a basic product appear more desirable. Appealing to higher sensations beyond just satisfaction; differentiating the same basic product into an up-scaled, up-market luxury item. The same item that customers will happily pay more for.

The retail price for a 50g bag of Walkers Salt and Vinegar crisps at my local One Stop is 35p. The price of the Sensations bag is 47p. (For reference the retail price of a 50g potato – is 5p). Now I’m no crisp expert, but I’d guess that the incremental cost for adding a couple of new ingredients to the flavour is marginal. There’s some sunk cost in product development- creating the new flavours and developing the new brand, but this is little effort compared to the benefits that will be accrued.

But that is not the end of the story. Focussing upon the experience of the Sensations product, Walkers see an opportunity to change the packaging – to increase the bag size. Now their basic Sensations product is a whopping 150g bag that retails at £1.35.

Sometimes it is easy to focus upon just delivering the basic package, to just satisfy the customer. Is there anything you can do on your project to transform delivering the hygiene of customer satisfaction, to selling a compelling value-added experience?

Cultural differences in toilet walls

Monday, 11 June, 2007
By: marc

What do you see? Depends on who you are. In the US it’s just a row of toilet cubicles. Elsewhere in the world it is “what’s with the huge gap between the floor and cubicle wall? A gap large enough to see the legs of the person in the cubicle next to me!”

Apologies for dragging this blog to the level of the toilet, but there is a point to this observation. Things that are normal in one culture may not be quite so normal in other, even the most mundane. On distributed projects with off-shore teams it is not enough to ensure you have robust processes and open channels of communication. You need to ensure that cultural differences are understood and respected. Don’t assume everyone shares your design of toilet.

It’s not what you’ve done, it’s what you’ve acheived

Wednesday, 6 June, 2007
By: marc

This is a good way to assess where you are going in life. It’s not so much what you’ve done, it’s more about what you’ve achieved. Great, so you’ve written a marketing plan, you are an expert in Java, .net and Ruby on Rails. But what have you actually achieved? What did that marketing plan result in delivering? Who did you delight with the applications you built in Java, .net or Ruby on Rails? What value have you personally contributed to the world? What would your epitaph be?

System Obituary

Monday, 4 June, 2007
By: marc

Talking about workshop icebreakers with Prashant and here’s an idea: participants write their own tombstone or obituary. “Here lies Jack. A life spent comparing numbers on an excel spreadsheet”…. You could even use Tombstone Generator to bring them to life:

Hmmmm, maybe not the strongest icebreaker (indeed it could kill your workshop before you’ve even started… If you don’t consider cultural sensitivities you could receive some rather blank looks, if your audience doesn’t have a dry sense of humour or doesn’t “get it” you’ll be in trouble…)

So maybe it won’t work so well with people, but how about systems? If you are looking to understand the current system landscape, why not ask the participants in your workshop to list out all the systems they can think of and ask them to write the inscriptions that would appear on the tombstone.

For example…

+

Customer System RIP
1997-2007

Dearly beloved wife of Position System and bastard child of Excel spreadsheet (1991-date).

Threw tantrums and refused to give the right answers when it really mattered
Grew bloated in size due to unwanted change requests
Lost self worth due to non-business value changes
(Died in the loving hands of Indian Outsourcing Company)

She will not be missed

+

Here Lies Position Reconciliation Spreadsheet
1991-2007

Father of Every Conceivable Problem

A real handful to manage but usually got there in the end
Local resident of Sarah’s Desktop, he never got out much
Prone to occasional lapses of judgement that were rumoured to cost the bank millions

He has gone to a better place (recycle bin)

And why restrict this to the current state. It could be a useful exercise in understanding what benefits a new system could be remembered for…

+

Here lies New System
2007-2017

Saviour of the Back Office

Banished reconciliation breaks to history
Defeated the multi-headed Legacy Dragon, bringing peace and harmony to the Ops team
A single voice of truth
Beautiful to look at, easy to get on with, she gave such joy to customers and added such value to the business

Without her Ops can no longer function

Blue sky apple pie

Thursday, 31 May, 2007
By: marc

I’m in Hong Kong in a workshop and we are asking the group to think beyond what they do today. To come up with a “blue sky” vision of what they want from an application.

“Urrrr, excuse me” says one of the team, “what is a blue sky?”

Earlier on, one of the team had talked about “motherhood and apple pie”. Urrrrr. What is that?

Another workshop, “We are interested in how you do things, soup to nuts”. Uurrrr, nuts? Who ends their meal with nuts. If that is what you are trying to say…

On agile projects we talk to customers and soon start talking about “stories”. Urrrr, aren’t stories something I read my daughter at bedtime
We assume that people will understand what “stories” are. They nod their heads in agreement, but do they really understand what we are talking about.?They’re requirements right? If calling them requirements makes communicating with your customers easier, then isn’t it better to use the words they are comfortable with?

When you do a retrospective (urrrr, what’s that? you mean review of how we got on?) how about spending a couple of minutes reviewing the language you have talked to your customers in. Have you spoken their language, or talked at them in your own? Have you communicated in plain English or have you been wallowing in bullshit bingo land.

Oh, and if I’m on a language theme, when you go into Starbucks it is “can I please have a cup of coffee”, not “Can I get a coffee”… 🙂

“Let’s pretend” user testing

Wednesday, 30 May, 2007
By: marc

How do you test the usability of the software you’ve built? At one end of the scale you could run full usability tests with a sample of users, given them a scenario and let them loose, trying to realise pre-set goals. On the other you could do guerrilla usability testing, just grabbing people and informally doing a usability test at your desk. You could get the experts in to do a usability review. They’ll typically use a bunch of usability heuristics and provide you with a report critiquing the application against the heuristics. But what if you don’t have the budget for usability testing, can’t get hold of any representative users, don’t want to wait for some experts report? How about playing “let’s pretend”? Remember playing doctors and nurses as a child? Well do it again, only this time be Users and Computers. And you’ve got the role of the user.

Create a persona, a pen portrait of your customer. Think in your mind how they act, behave. Maybe you know someone like them, seen someone like them in the supermarket. Now ask yourself some quetions:

How do they behave in their daily interactions with others?
What does their life look like?
What experience do they have with using computers, with using products like yours? How much time have they got? How are they feeling?
Why are they using your product?

Spend a few minutes internalising the persona.

Now turn to your application and imagine you are the persona, using it for the first time. Give yourself a task to complete (make sure the task is something real that your persona would look to achieve, not a goal you think the application will help him achieve – there is a subtle difference). Try and forget all you know about the application (easier said then done) and be the novice user. Walk through the process, speaking aloud (in your head will do). Focus upon I not “the user”.

“I’m looking for this, I’m looking for that. I do this, I do that”. I can’t find this; I don’t think that makes sense”

I want to check my balance. Hmmmm, there are three “balances” here; I’m not a banker, what’s the difference between Running balance and Cleared balance?

I owe my mate some money for the golf holiday, he’s given me his bank account details, I want to transfer some money into his account… huh? I can’t do that. What do I do? Pay a bill? He’s not really a Bill is he… Etc etc.

You don’t need heuristics for this – many of issues the heuristics would help uncover should come out using this method anyway (speed, ease of navigation, speak users language etc). If your persona is having difficulty you can probably multiple the usability issues for a real user.

This approach works for a quick and dirty review of an application’s usability. And if you document your experience make sure you preface it with a description of your approach. Someone who is close to the development of the application, reading your first person critique, is rightly likely to think you are an arrogant so and so. I speak from experience.

Won’t you please… be concise

Saturday, 26 May, 2007
By: marc

Won't you please give this seat to the eldery or disabled

Seen on the New York subway. Is the “won’t you” really necessary? The tone of the notice is trying to be friendly, but surely when you are writing signs or labels it is better to be concise and to the point. Afterall, it’s a sign, not conversation.

Heard on a suburban comuter train going into London, a pre-recorded generated message. “London Underground inform me that there are currently no delays on the system”.

“Inform me?”

The “me” is a recording. Again, the tone is trying to be friendly, but it is not real.

When communicating to customers use a style that is appropriate to the media. If it is impersonal information you are providing, be concise and unless it is coming from the mouth of a human in real time, don’t try to fool me that it is otherwise.

Let the UI drive the requirements

Thursday, 24 May, 2007
By: marc

Conventional approaches to building software applications start with a Big Idea. Someone needs (to define an application) “a program that gives a computer instructions that provide the user with tools to accomplish a task“.

Someone picks up the big idea and breaks it down into a smaller list of “requirements”, things that the application must do to fulfil the Big Idea. In conventional waterfall development Business Analysts will spend a while documenting the list of requirements in some detail – in agile approaches they will do it as they go in a far more “lightweight” manner. Maybe a technical architect will draw up a blueprint design of the solution. Regardless, soon the developers will start writing code. With either agile or waterfall the user interface usually only starts to emerge at this stage. Until then, everything is coded in words (and maybe some boxes and arrows showing flow). Only late in the process does the UI emerge.

Returning to that definition of an application, IT development seems to spend most of its time in the “a program that gives a computer instructions” world, and often looses sight of “provid[ing] the user with tools to accomplish a task”.

How about a different focus. Start with the user interface. Take the Big Idea and illustrate it. Draw pictures of what the tools will look like, how the user will interact with them. Sketch storyboards, wireframes, lo-fi prototypes, paper mock-ups, call them what you will. Use this as the primary requirements document, supported by explanatory text and detail where we required. These may be stories or use cases, but let the visual representation of the big idea drive the requirements rather than it being almost an afterthought. Start with the UI and specify the functionality from that rather than the other way round. After all, it will be the UI that the user uses to accomplish their task, not the computer instructions.

Apple in the Big Apple

Wednesday, 23 May, 2007
By: marc

New York. Went to the Apple store last night with the intention of buying a MacBook. The Apple retail experience is pretty cool, lots of space, Macs and ipods to play with, sales people in the background – letting the Apple products sell themselves, being available to answer specific questions and take orders.

And then cold feet. I’ve been taken in by the hype. Do I really need a new MacBook? It would be for work and work already provide me with a reasonably decent Dell laptop. Can I really justify the $1200 outlay (even though it is cheaper than in the UK? And there’s a thing that bugs me about the retail experience in the UK. Lack of pricing transparency. The ticket says one thing, but then you’ve got to add the sales tax. In the UK, unless you are buying in the B2B space the price you see is the price you pay). And my final decision was no. I can’t really justify it. So instead I’m going to give Ubuntu another go and try and have the best of both worlds, a cool operating system on my old Dell machine.

Humanising the corporate voice

Tuesday, 15 May, 2007
By: marc

Friday evening, the train is pulling into East Croydon railway station. There’s an announcement.

We are now approaching East Croydon, please mind the gap between the train and the platform. Don’t leave any of your belongings behind…

The usual scripted stuff. Then…

Hey! I’ve just realised its Friday! The Weekend is here.

People on the carriage look up. Did he really say something, that’s something that breaks the mundane monotony of the commute.

Remember folks, drink sensibly!

I looked around and people on the carriage were smiling. An unscripted, personal touch. It wasn’t a canned message from an anodyne voice. For a brief moment South Eastern Railways became really human. It made commuters smile. And commuters travelling into East Croydon rarely have anything to smile at.

There is more to Customer Experience than homogeneity and consistency in interactions. It is more than scripting customer contacts. It is more than sheepishly adhering to the corporate line. It is about empowering employees to have the confidence to be human. It is giving employees some degrees of freedom to do things differently if it is in the interest of the customer. To be spontaneous.

There’s the story of the Ritz-Carlton bell boys being given a budget to help customers. To be spontaneous without having to jump through hoops of approval. No “I’m not really sure, wait a minute and I’ll ask my supervisor (because even though I’m grown-up enough to want to help you the Rules by which I’m employed don’t let me)”.

Maybe I’m getting a bit carried away. But customers remember these human touches. And if they have the seed of a positive emotion planted in their memory, an emotion associated with your brand, you have the seed to grow lifetime value.