innovation

Is this the most stupid question to ask?

Someone from the Barclaycard research centre rang me today doing some customer research. It is great to know they take the customer experience seriously – many of the questions were around my experience with the brand. But then they dropped this corker, not once, but twice.

To what extent do your other credit card providers offer innovative products

How important is it to you that your credit card provider offers innovative products

How on earth did those questions get through and on to the list? What is an “innovative product” when talking about credit cards or financial services? What is an “innovative product” to Joe Public? Maybe I can relate to an iPhone as such, but my credit card? Product innovation is hardly something that you or I consider when we pull a credit card out of the wallet.

“Innovative products” are something that marketeers talk about, they are not in the credit card users lexicon.

What not how

All too often the business thinks in terms of the “how” rather than the “what”. But why should they care how something is to be implemented? Why doesn’t the business state their requirements in terms of their desired outcomes? What is it that they want? Then, and only then should anybody think about the “how”.

Sadly, focusing upon the how rather than the what is a driving factor behind so much of the mediocrity in enterprise software. Rather than stating “what” (they want) in terms of their dreams and aspirations, the business express their requirements in terms of what they perceive IT can deliver. “What” could never be the design quality of Apple (visionary) because they believe the “how” (their IT team) is not Apple (mediocre). But wouldn’t your average developer rather be building something visionary than something mediocre?

Innovation and the idea approval index

I’ve written in the past about organisations setting up test and learn capabilities, and how languages such as Ruby on Rails make this so much easier. Sadly, even with the best will in the world it is not unusual for these internal skunk works outfits to fail. Scott Berkun’s recent post gives a good reason why; they score highly on the Idea Approval Index where the higher the number, the harder the innovation is.

If you are going to be serious about test and learn it is essential to remove barriers to its success, and that means removing bands of bureaucracy and sign-off. Identify the number of approvals you assume will be required then plan how to eliminate them. What strategies can you put in place to keep stakeholders in the loop, but at a distance so they can’t kill the innovation before it’s given oxygen to breathe. Realise that what is being tested is a “beta” and market it as such. Give clear terms and conditions, use controlled environments (for example testing on staff within the internal network), anything to prevent it being subject to the usual legal / compliance / architectural constraints.

Unleashing innovation at speed

It sounds clichéd and old hat, but it is true. Truer now than ever before; the web is an enabler for new ideas. It provides you with the tools for disruptive innovation. Sadly for too many organisations it has become a hindrance.

A recurring theme with many organisations is the length of time it takes to take an idea to market. Especially in retail financial services, where you would expect lead times to be short it is not unusual for innovations to take a year to implement. This seems crazy, it’s not as if there is a physical product to manufactured.

So where are the hold ups? More often than not, they are rooted in the organisational structure. Innovative products often cross business boundaries; whilst customers only see the a single brand, different product teams only see what they are responsible for. They have own objectives that often conflict with other parts of the business; gaining agreement and consensus across all parties can often be a time consuming and painful experience that slows and often kills innovation.

Then there is the technology. Changes to systems have to be scheduled (along with every other request). Unproven ideas are put to the back of the queue. The business starts to perceive IT as a hindrance rather than an enabler and lines of conflict are drawn up.

Channel is the next hurdle to cross. Typically a face to face channel or telephony will be easiest, but getting something on the web? Now a new area of the business needs to be involved, the Internet Channel Team who interface between the business and IT. They’ve got to design web pages, get the creative done, produce requirements for technology to build (and schedule into deployment for which the dates are even further into the future), do usability testing… Long lead times are inevitable.

And then, before the innovation sees the light of day, someone new comes in to rationalise the product portfolio, the innovation doesn’t quite fit in with their new priorities and it is quietly ditched. This half hearted attempt at innovation has taken a year, cost in excess of a million and has come to nothing.

There has to be a better way.

There is. Do things at speed. You can start by sticking some amphetamines into ideation phase. Someone’s got an idea; identify who has a vested interest in it succeeding (or failing) and get them into a room to thrash it out. This doesn’t need to take long. Workshops are best limited to 90 minutes at a time (after that people get Blackberry withdrawal symptoms and loose interest). But if all the stakeholders are geographically dispersed, a structured day’s off-site might be the best solution. Avoid letting people dial in or video conference, this is one meeting where people have to be there in physical presence. Also avoid having too many people in the room, especially when forming ideas (there is a trade-off between having the right people and too many people to make the process unmanageable). Start with the users, the customers, the people whose lives will be changed by the idea. Scribble out personas -describe who they are, what their goals are, the perceptions of your company, of technology. Print out pictures of people that represent the personas, rip out photos from magazines, anything to bring them to life. As the idea takes shape, turn it into pictures. Draw out the customer experience. What would the persona do at each stage. Far better to do this than write it down in a document that can be open to interpretation. Illustrate the touch points. What does technology need to do. (Can we be pragmatic and use roller skate implementation rather than getting bogged down in an integration quagmire?)

Now is where it gets interesting. There once was a time when you would need to invest time and money into producing a heavyweight business model and business case for the innovation. You still need a business case, but at this stage it probably doesn’t need to be too robust; make some basic assumptions then test it. All too often business cases are built on flaky assumptions; build something quick, test it and get real data to build your models on. Again, this is about doing things at speed; a couple of weeks after the first workshop there is no reason why a small team of developers can’t be actually building something to bring the idea to life. So the team is using Ruby on Rails to build a proof of concept. There may be disquiet that this doesn’t fit into the current technology stack – doesn’t matter, it is a proof of concept. Six weeks later the proof of concept is done. It is not a static, prototype that demonstrates linear page flows, it is fully featured and fully functional. It can be usability tested (but more likely you were doing that on wire frames alongside the build). What then? In two months you’ve taken your idea and turned it into something tangible.

Why not put it into the market for real. Whilst IT might not want this Ruby “thing” on their stack, that doesn’t mean it isn’t possible and can’t be done. Large organisations have a testing ground of consumers inside a secure environment – their staff. Use them to beta pilot the idea? Friendly customers are delighted to be part of product development – put it out to a small and selected group of customers, and have some smoke and mirrors processes to handle fulfilment. The objective is to prove the viability of the idea, get data to make informed decisions and make your collective mind up quickly. To fail fast or succeed cheaply.

What is your business

Should “the business” care about IT? Should an investment bank trader know anything about XML, or a marketer know anything about SQL? Probably not. Even less so should they be talking to their IT colleagues of their requirements in these terms. The business should speak to IT in a language of value driven requirements rather than implementation detail. What is the outcome you need or want, not how you think IT should deliver or implement it.

Yet in many organisations (especially where IT has historically had a track record of failure), the business has taken a greater interest in IT delivery. They start talking the language of the techie. When this starts to happen business operations no longer see the clarity of their business. They see systems. In an investment bank setting: the trade is booked in Zeus, settlements are handled by Minotaur, payments by Socrates. Corporate actions are handled in Hades. Depending upon the geographic region, client management might be handled by Tomsys, Dicksys or Harrysys. You ask a business person what do they do and they talk in terms of systems. Getting down to the underlying requirements of what they actually want to do is hard. Innovation and creative thinking are hard because they always return to what the limitations of the current systems are. They focus upon the requirement for a Reconciliation System rather than asking why there needs to be any reconciliation in the first place.

So here’s a suggestion. Act dumb. Forget everything you know about the way you do things and go back to first principles. How would things be if we were starting from scratch? How would you describe your business intent (not the what you do now, rather what outcomes you really want to achieve) in simple terms to a complete novice. I doubt the word “system” would come into the description.

What does Web 2.0 look like?

Here’s a presentation I recently put together on digital strategy and what Web 2.0 could mean to a fictional jewelery company. It rapidly introduces some of the key concepts then presents a customer journey through a “what if” scenario. Apologies for the poor audio!

[slideshare id=1140985&doc=cdocumentsandsettingsmmcneilldesktopmarc02-projects45-dtcjewellery-090313063919-phpapp02]

Make something consumers love

Bubblegum generation presents a compelling model for Apple’s iPhone strategy:

1) Pick an industry which sucks (ie, imposes significant nuisance costs/menu costs/externalities on consumers)
2) Redress the imbalance by making something consumers love
3) …Which disrupts the long-standing industry equilibrium, and shifts market power
4) Use said market power to redesign (a hyperefficient) value chain

Don’t think that organisations in industries that suck don’t aspire to “do an iPod”. Go to any proposition development or product strategy workshop and it won’t be long before someone is mentioning Apple products. Yet all too often they fail to do anything truly revolutionary; they end up doing something different rather than “Redress(ing) the imbalance by making something consumers love”.

Do customers want something that is different or something that is just better?

Interestingly, little functionally in the iPhone is new. Like every other phone on the market it makes phone calls, sends messages, receives emails, takes photos and allows users to listen to music. Nothing different or new there… other than being better than every other phone on the market.

What Steve Jobs espouses is the experience of the phone. He says “So, we’re going to reinvent the phone. Now, we’re going to start with a revolutionary user interface… Now, what’s the killer app? The killer app is making calls! It’s amazing, it’s amazing how hard it is to make calls on most phones.”

He’s not looked to do anything radically different, rather do it radically better.

So how do you bring revolution to your product set? Rather than trying to be different, why not try to better. Make something that consumers love?

Take a leaf from the Apple book and focus upon the experience. Design and attention to detail are critical. Moving beyond purely functional and satisfying products to crafting experiences that engage the emotions. In agile product development it is often easy to focus upon delivering functionality that is perceived to deliver business benefit, yet end up with a mediocre product that has little resemblance to the original idea it was meant to become. Incremental delivery is a key feature of agile; it means you get stuff out there early and often. The challenge is to identify what that stuff is. To make something that consumers love using the agile approach, in addition to great developers and focussed project management, you need three people;

1. A passionate sponsor who has a dream and a vision and can articulate that to the team, banishing mediocrity from the outset
2. A business analyst who will help the team slice the functionality according to consumer needs and desires; that take the consumer of the journey they want to travel, not a predefined route that constrained to picking those features that eventually will deliver greatest value.
3. A customer experience architect, interaction designer or graphically minded usability dude who can champion the product aesthetic and usability.

Get them on your side and maybe you might be taking the first step on developing a better gizmo that your consumers will love, and sleep outside your retail outlet for hours to buy one.

Are you building a potato or a Sensation?

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

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

Walkers salt and vinegar crisps

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.

Walkers Oven Roasted potato crisps

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.

Walkers Lime and thai spices crisps

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?

System Obituary

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:

Tombstone

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

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”… 🙂

4 of 5
12345