The cemeteries are full of people who thought they were indispensable.
If you didn’t turn up to work tomorrow, if you never came back, what would happen? I mean, what would really happen?
The world wouldn’t stop.
Can you hand on heart say it would be the end of your organisation? So you may be the ‘key man dependency’, but is that your ego making you think that? (OK, so I once worked with an organisation who had one of those. Their system was written in some obscure language that only one person knew its inner workings. He spent his weekends base jumping. Our job was to migrate the data to a new system to alleviate this risk).
When was the last time you took a holiday? Been too frightened to because you fear everything will fall to peices when you’ve gone? Get over it. Take a vacation, Nothing will change whilst you are away. You’ll get back and nothing will have changed.
What is indispensable?
OK. Now think bigger. History is full of organisations who thought their products and processes were indispensable. Of the FT30, (the oldest index of share prices started in 1935) only one company (Tate & Lyle)is still there after seventy five years.
What do you think would really happen if your organisation ditched all that process and product baggage it held onto so closely? What would really happen? Are your current ways of working really indispensable? How about your business model? Maybe time to do some scenario planning to ask precisely those questions?
<Personal Interlude> Eight months ago I was a lazy tub of lard. I could barely swim the length of a pool, my bicycle had two flat tyres and I’d be breathless and beaten after running 50m to catch the train. I looked for a goal, something that was outside my comfort zone, my frame of reference. I entered the London triathlon, sprint distance. Completing a triathlon became an unobtainable dream (you have to understand that I went to Loughhborogh University, home to the Jocks, [and a rather good Human Sciences department and Ergonomics course, hence my attendance there], I felt totally alienated from all the sporty types, and triathlon represented the pinnacle of pointless exercise and sport). And slowly started training for it. Running, I hated. My first swimming lesson I discovered the need to breath. Cycling, I discovered the ride to work scheme and bought myself a decent bike. I put myself on a change programme. A programme of gradual change. Baby steps. And a few weeks ago it all came together at the London Triathlon; the swimming, the cycling and the running. A multi-disciplinary effort, a radical change to my being. And I completed it. In a not overly embarrassing time; in fact I can in the top half. but better still, I ended it charged up with how much faster I could have gone, now that I know what it is like. I paced myself too slowly. I’m buzzing on triathlon. </Personal Interlude>
Organisations I see are like the tub of lard I was. Full of inertia, and reasons why they can’t change, why they can’t be triathletes.
Yeah, wouldn’t it be great to be an Apple… But we just don’t have a Steve Jobs. Reasons why you can’t rather than inspiration, spirit and belief in why you can.
There is nothing in your organisation that is indispensable. There is no reason why you “can’t” other than your own myopia and inertia and inability to dream the future and train and practice to make it happen. All you need to do is get over the inertia and make it happen.
Something that is common with the start-ups I’ve been involved with, and stories of entrepreneurialism you can read is the passion of those involved. They have a drive and desire to succeed, backed by enthusiasm and belief for the product they are building. More often than not, they are personally invested in the project; maybe it is a problem that they feel needs addressing (Dyson), or an opportunity in an industry they are familiar with. It almost always it goes beyond just a job, it is a hunger to bring change and make a difference. They have a vision, it what drives them, yet they are willing adapt the original vision and move with agility as circumstances dictate.
FlickR started its life as a tool in a role playing game. The game was not successful and ultimately shelved (fail fast) with the photo sharing capability being developed; the team realised where the value was rather than sticking to a failed big up front plan. If you go back in time to 1999 and look at how google described itself:
Google Inc. was founded in 1998 by Sergey Brin and Larry Page to make it easier to find high-quality information on the web.
Nothing there about browsers or phone operating systems or word processors or spreadsheets. Twelve years to go from a search engine to the Google we know today. Place that lens over most enterprises and how have they managed to adapt to the changing world? I know of several enterprise projects that are three plus years in, (that’s a quarter of Google’s life) and have still yet to start delivering value. You don’t get that with start-ups, or places where vision, passion and personal investment drive the product strategy (thinking Apple and Steve Jobs for example).
I’ll lay the fault at Enterprise Culture. Silo thinking and career progression through the ranks. So an individual is personally invested in delivering documentation that specifies the system. When she delivers these she is done. What happens next is someone else’s problem. Reward is rarely for delivering the overall vision, why should it? How often do all stakeholders involved in a project have a strong grasp of the what’s and why’s of what they are doing? They are only rewarded on the how they deliver the fragment that they are responsible for.
When IT becomes a supplier rather than a partner, no-one has ultimate responsibility for delivering a coherent holistic vision, it becomes a contractual relationship rather than a passionate obsession. Funding projects is all to often a charade and a nonsense. The business submit their funding requests (a line item for a potential project) for the forthcoming financial year in the autumn / winter. Budgets are finalised in the Spring with the new financial year and months have elapsed due to internal budgetting and accounting formalities rather than the ability to respond to the market. Contrast that with the start up model with seed funding to get started and if the projects shows viability second round funding follows. If the project is not viable it is suffocated before wasting cash. (There are interesting perspectives on this leaner model at Beyond Budgetting).
I wonder if in these lean times we are going to start seeing lean thinking applied to enterprises and a start-up culture being nurtured. There is certainly a growing interest in agile, beyond the practitioners and from C level executives. But agility in software development is only the first step. To be really successful it needs to spread through the whole organisation, not just paying lip-service to the word “agile”, but devolving responsibility to individuals and collaborative, cross-organisation teams who can share the vision, passion and are personally invested in getting the right quality products to market at speed.
Chances are the business card you hand out is that of your employer. It’s got your name, title, company logo and address on it, but does it really say who you are? The stuff you blog about, your professional tweets, where are they? Do you hand out another card with your personal details on it. Whilst at Leancamp, Nicky Smyth handed me her (BBC) business card. Alongside her BBC details, she’d used an ink-stamp to provide her personal URL and twitter account. I’ve not got round to getting a stamp created, but when we were blogging round the world, in Lijang, China I had a stamp made up with Dongba script, pictographics from the Naxi people and the dancingmango URL surrounding them. I’ve been using this to pimp the back of my ThoughtWorks business card.
A cleaner and a doctor both watch a surgeon perform a complex operation on a patient. Both watch the same operation, yet each sees a completely different thing.
Are you aware of how different people will see the product you are building?
In designing user interfaces there’s a lot we can learn from systems where failure to consider human factors has resulted in terrible consequences.
On 8th January 1989 British Midland Flight 92 crashed whilst attempting an emergency landing. There had been a fire on one of the engines which led to its malfunction. The captain reacted by shutting down the engine. Only he shut down the wrong engine. With no power, approaching East Midlands airport the captain manged to glide the Boeing 737-400 to avoid Kegworth village but crashed short of the runway. 47 people died.
The investigation into the Kegworth air disaster identified engine malfunction (the engine used in the aircraft was an upgrade of an existing engine and had not been field-tested) as causal factor, however the report concentrated upon the failure of the flight crew to respond accurately to the malfunction. Human error was the primary cause.
The truth is a little more complicated than that. Why does a captain with over 13,000 hours flying experience and a first officer with over 3,000 hours experience shut down the wrong engine?
A number of human factors contributed to the disaster including organisational issues (refer to this paper for discussion of the role of managerial failures in disasters) and cognitive overload. But of equal importance (and indeed buried in the appendices of the Investigation Report appendices) is the issue of design. Around 50% of accidents and incidents in the aircraft and nuclear industries have a root cause in design (source).
Take a look at the cockpit controls (taken from the investigation report). The left image is for the earlier 300 series and the right for the 400 series aircraft on which the captain had only 23 hours experience after a one day training course.
The actual cause of the engine malfunction was a broken turbine, itself the result of metal fatigue caused by excessive vibration (source). Had the Captain noticed the Vibration Warning display he probably would not have made the wrong decision.
The Vibration Warning display on the new 400 series was in a different place to the 300 series, but more critically it was designed to be significantly smaller “the dial on the vibration meter was no bigger than a 20 pence piece and the LED needle went around the outside of the dial as opposed to the inside of the dial as in the previous 737 series aircraft” (Source: Wikipedia). Take a look at the arrow on the left hand image, the display dials on the 300 series use mechanical pointers. On the 400 series they were redesigned with short LEDs rotating around the numbers. These, as the investigation report noted “are much less conspicuous than mechanical pointers, acting more as scale markers, and providing less immediate directional information).
The report criticised the layout of the instrumentation and helpfully suggested an improved layout. The layout was (and as far as I can tell, remains in 737s) split into primary instruments and secondary instruments. The issue with this layout is that the dials are not spatially aligned with their associated power levers. If the pilot is focussing upon the primary instrumentation, the secondary instrumentation is in peripheral view. This layout will lead to attention based around specific instruments rather than engines.
Compare this to an alternative design that the report provides where the dials are aligned to their associated power levers. The report recognises the design trade-offs here but concludes that to break the left-right mental association with the engine position was probably not the most optimal solution.
The 737 involved in the East Midlands crash had ﬂight deck engine information that lead to confusion under mental pressure. Placing the secondary information sets for both engines to the right of the primary set broke the implied rule set by all the other engine information, that the left engine had left hand controls and indicators (and vice versa). If one assumes that the optimum positioning of indicators is the one that requires the least mental processing then a simple symmetry about the aircraft centre line seems appropriate. The actual positions required a mental spatial transposition of one set of dials to the other side… The readability of the indicators had been reduced by the substitution of electro-mechanical readouts with electronic readouts, but which simulated the old design. Possibly the redesign to electronic readouts should have taken the opportunity to use a rather different layout, possibly with linear indicators rather than rotary ones.
OK, so lots of words, but what is the point of this to what I usaully blog about? The issue is one of design and layout and who’s responsibility is it. In designing user interfaces UCD is often seen as a luxury, developers believe that they can design a GUI as well as anyone, and stakeholders (especially on internal projects) will question the value that a UCD person can bring to the project. Does a developer or an engineer by training and instinct stop to ponder the human factor and the human consequences of the GUI layout? What are the consequences of this? As can be seen from Kegworth, seemingly minor changes to the control layout can have a signficant impact on the safety of a complex system.
Only Five Percent Of Readers Would Pay For Online News. (Sep 20, 2009)
16 November two new reports come out simultaneously.
Research from Boston Consulting Group suggests that as many as 48% of British and American consumers would be willing to pay a few pounds a month for online news.
So 5%, 20% or 52% of people will pay for online newspaper content. Or maybe 12%. And Murdoch is going to “rewrite the economics of newspapers” based upon that kind of customer insight? It is going to be interesting to watch.
Velocity is a simple concept to grasp when planning and managing an agile project. It is one of the first formula you learn in maths (or is it physics), speed equals distance over time. On a project the distance is scope, measured in the number of ‘points’ you need to complete. So if the team has a hundred points worth of scope and a velocity of ten, they will complete distance (scope) in ten weeks. It’s a simple calculation, but is dangerous and wrong. It fails to take into account acceleration.
Just in the same way that it takes a car time to accelerate to a meaningful speed, so a project takes time to reach it’s planned velocity. To reach 60 miles an hour takes ten seconds and means moving through the gears. You don’t put your foot on the accelerator and suddenly find yourself doing sixty. Nor do you put the car into forth gear and expect to move without stalling. It is the same in agile projects. Velocity is misunderstood; you cannot expect to have your planned velocity immediately without acceleration. Similarly, putting a fall sized team onto a project is like trying to start in forth gear. You will stall.
When planning an agile project you need to consider acceleration. The first iterations will be slow as you come up to speed. Secondly you need to be in the right gear for where you are at. Start in first (small team) and change gear (ramp the team up) as the velocity requires it. Better to have the engine screaming in first (change gear) than to have it stall before it’s even got going.
Sadly, this means the simple pictures on burn-up and burn-down charts are wrong. They need to take into consideration acceleration and appropriate gearing. And that is advanced maths.
The customer is the oxygen that keeps a business alive. No. The customer is more than just the oxygen that keeps the business alive, (my mother was recently on a life support machine with Guillian Barre Syndrome; she was getting oxygen but paralysed, unable to move. With that condition you see that life is more than just about breathing oxygen). The customer is more than just corporate oxygen, it is the reason a business lives for.
Shareholder value means nothing if the organisation doesn’t provide value to the customer. Yet I see far too many organisations who fail to grasp the importance of their customers. They prioritise their internal processes and policies to the detriment of customer satisfaction. They focus upon narrow propositions that represent organisational silos rather than meeting the broad needs of the customer. Innovation is morphed into ‘requirements’ that are performed by ‘actors’ in multiple volumes of ‘use cases’. To my mind, too many organisations are struck down by corporate Guillian Barre Syndrome. The brain knows what is going on but is powerless to act. It feels pain, it senses something is wrong but is paralysed, it cannot move. Prisoner in its own body.
If that is the diagnosis, what is the cure? There are many, but a starting point would be to place the customer at the heart of your design. Don’t start any proposition without the customer experience at the core. Create personas and walk through customer journeys. Use scenarios to develop your thinking. Broaden the scenarios to introduce what-if models. If it is an internet offering, sketch out the screens, if it is a service, sketch out the touch-points with your people, processes and technology. Don’t allow the proposition to be talked of in the abstract, work with the concrete. Would a persona accept the experience your proposing? Would she accept that pricing model? Does that journey make sense? You do not need to spend weeks and months documenting the exercise. A couple of days with the right people in the right room with white boards, post-it notes and business-speak banished from the proceedings should deliver far more fruitful insights than playing document-tennis with revision after revision after revision. You may even kill the proposition before you invest too much time on it. Or better still identify a better, customer-centric proposition waiting in the wings.
There may be a niche in the market, but is there a market for the niche?
How do you create a successful proposition? If the answer was obvious there wouldn’t be so many failures out there in the market place.
It is easy to commence on a journey of product development with a hunch and clearly there is no substitute for validating ideas in the flesh. That something at ThoughtWorks we do; helping clients test and learn, rapidly building ideas into tangibles that can be piloted at low cost and low risk before investing in significant build and spend. However, sometimes a little more rigour is required before you commit to commencing a project in earnest.
That rigour needs to be focused. What often happens is this rigour turns into a research phase that turns into a project itself. It need not be this way. There are certain things you can do, certain questions to ask as you set out on the journey of creating a new, compelling customer proposition. What follows then is a strawman customer value proposition model to help test potential propositions before moving forward with them. There are three components to the value proposition model; the customer, the environmental context and the organisation or company.
All too often propositions are rooted in the organisation. They make assumptions about the demand or usage. This model attempts to broaden the analysis and focus upon the customer and the why the proposition will be attractive to them. The model supports questions that may be asked to help shape thinking, test hypotheses and validate thinking.
I do not propose that this should become a major research exercise (for example market sizing is a huge effort in itself), rather a tool for asking the right questions, and if the answers are hard to come by, maybe that suggests more thought is required in refining the proposition.
So here goes, a model that provides a framework for considering new customer value propositions. It’s just an initial idea and I’d welcome feedback and suggestions.
Before you get too carried away with the proposition, a good starting point would be the customer. Who are they and what do they do. Let’s remember that your customer is not everybody. Your proposition in unlikely to be appealing 24/7. The challenge is to segment your target market and identify the triggers for action.
The persona: Who do?
Personas are a useful tool for bringing the customer to life. Much has been written about them, but they are a useful tool for extracting broad data into specific stories that describe individuals. Realise that it is unlikely you will design for everybody. Start with the market that you are targeting, how large is it and what is its propensity to spend? Then within that target market segment the target customer base into different profile customers (personas). You need to understand which persona, which customer profile is most important – prioritise them and focus on the highest value. This may mean deciding between high volume, low margin mass market and low volume, high margin niche appeal. This decision needs to be made as early as possible to ensure the proposition remains focused and doesn’t try to be all things to all people, satisfying none.
Values, needs, wants and desires
People are not empty vessels waiting to consume and be filled with your proposition. Their behaviour is driven by their values, needs, wants and desire. These may be fundamentally rational (to satisfy a basic human goal) or emotional (to demonstrate status). They are cultural and time based. Thinking in these terms helps you understand how the proposition will appeal to the customer at different levels. Let’s take an example of this; a new mobile phone.
Before we think about what the product must do, what are the values that the persona associates with the phone. Is our target market a technophile or a technophobe? Jan Chipchase who works for Nokia includes ethnography in his research to understand how people use their phones; women carry them in their handbags, men in their pockets or their belts.
The basic need that the phone must meet to satisfy the customer, she must be able to make and receive calls. If the product is unable to meet these needs it is not fit for purpose and the phone proposition will inevitably fail.
Just making phone calls meets the need but there are additional wants that should be satisfied for the product to be more compelling. It’s a hassle to remember the number of every person she rings, the customer wants to be able to store numbers and see the number of the person who is calling.
Having the ability to see a photograph of her daughter as a screen saver on her phone is neither a need not a want. The phone is useful and usable without that. But the customer desires to personalise her phone by having a picture of her daughter on it. Desirability is the key differentiator of the iPhone. It doesn’t need to compete on features, it is a cool device that people talk about. And here is a key decision you need to make on your proposition journey. Are you looking to compete on parity or whether you want to make a difference.
- What is the basic need that the proposition is trying to fulfil?
- What counts as hygiene?
- What does the customer need to be satisfied?
- What does the customer want in addition to being just satisfied
- What do other competive products do to maintain feature parity (if you feel you really need to compete on features alone – bad move!)
- Few people would argue they don’t want simplicity and clarity in their interactions with products. How could your product to make life easier for the customer?
- What will make the customer feel good in themselves about owning the product?
- What other products are “cool” or desirable to your target market. How can you leverage the essence of those products?
So now we are beginning to understand who the customer is, it is time to nest the proposition in terms of their context. The old maxim that a half drunk bottle of water in a desert is worth its weight in gold, but on the streets of a city is worthless trash, should be remembered. Even the best of propositions will deliver little value if they not only consider the customer, but also the context in which they apply: time, demand and usage.
So the next step in the model is to ask why, when and how will the customer be attracted to the proposition. What is the trigger that drives the customer to move from awareness (assuming you have that) to action? There is no point in a financial services company trying to sell me a car loan if I am wealthy enough to own my own car, or I do not drive. Understand what triggers the customer to be interested in the proposition, when and why this happens. How can your proposition be at front of mind when the trigger is set.
- What lifestyle / lifestage events will trigger?
- Internal events personal to the customer; leaving school, getting a first job, getting married, moving house, retiring etc
- External events that they have no control over (think about sports sponsorship and tying a proposition to that sport, or tying a proposition to a celebrity e.g. Michael Jackson..)
It is very unlikely that the proposition will be wholly unique. What is the competitive landscape, what noise will it need to be heard above to capture the consumers attention. Whilst you may review the immediate competitors to see where threats and opportunities lie, what can you learn from other, unrelated products or domains? How can you fuse together concepts from outside your immediate focus to bring new innovation to your product? Scenario planning may come in useful, playing out different outcomes for different timelines other than that which you plan for.
- What is the competitive landscape?
- What can you learn about similar but unrelated propositions?
- Have you considered the political, environmental social and technical influences using the old PEST analysis?
- Have you considered different scenarios and how your proposition would play out under them; what unplanned disruptors could get in the way, or how could your proposition done differently disrupt the market?
The experience engine
Enough of the customer and externalities, what will the proposition look like and why will the target customer go with it? There are three engines within the organisation that drive the proposition, the experience, delivery and value engines. So…
To be any good, the product has got to offer basic utility. It has to do what it says it is going to do. Sadly, too many products and customer propositions end there. A utility product will match the consumers needs. This is where most enterprise software sits…
- What are the key customer needs that the proposition must fulfil?
- What is the basic core functionality that must be met, what are the features that must be offered to gain traction in the market place?
- What features that are typical on competitor products that we could do without?
I could call this next box usability (as this follows the UXD model) but I think it goes beyond just usability. What is the quality of not only the immediate interface, but also with the supporting functions? For example, if you have a call centre to back up the proposition, how many layers of IVR are you forced through?
- Have you considered usability?
- Is the packaging aesthetically pleasing?
- The “happy path” customer journey may be well framed, but what about the “sad path”? What about when things go wrong, what about when customers don’t act in the way you expect of predict them to act?
It is easy to get carried away with a new idea before thinking about what it means to the brand. Typically there will be a strategic roadmap and whilst the proposition may be attractive it may not fit into where the brand is going.
- Is the proposition complementary to the overall brand direction or does it require a new brand and identity?
- Does the proposition support / leverage the brand?
- Does the brand already ‘do it’ under another guise (are you reinventing a wheel that has already been tried somewhere, sometime in the organisation’s history?)
- How will it be marketed?
Finally, what is the ‘buzz’ that the proposition will create, what will get people talking and sharing it and how will you create this buzz.
- Is there a social network component built in that gets people talking and connected? How will it get people talking in external networks?
- What will cause people to recommend it to others?
- How can customers become part of its evolution?
- What of the proposition will get people passionate, what will drive them away?
A successful proposition needs not only a talented, passionate and committed team to deliver it to market, it also needs a similar team to run it and support it when it is live. It is a common failing for a rogue “skunkworks” team to emerge in an organisation and develop what appears a compelling proposition, only to have it knocked back and closed down by the “Business as Usual” processes inherent in the organisation
- Who do you need to make the proposition successful? What is the team?
- Who will create the proposition and who will lead it? Is it IT led or business led?
- What are the cross-organisational boundaries that the proposition crosses and how will these be eliminated?
- Who will take ownership of the proposition once it crosses over into the market?
- What are the processes that will be required to sustain the proposition?
- If the proposition will require changes to the organisation, how will they be managed, communicated and rolled out?
- How will the proposition be supported once it is let loose in the market?
- How will it be communicated to customers?
- How will you create new sales – sales force.
- What is the technology that will underpin the proposition?
- Is it possible to test the ideas using rapid languages such as Ruby on Rails before committing it to the enterprise Java stack?
- What integration is really necessary and what can be worked around?
- How can you deliver a beta version in the shortest period of time?
- How will you avoid heavyweight frameworks and develop incrementally to deliver value early and often?
- How performant and scalable must the innovation be?
At its most simplistic, how much will the proposition cost and how much revenue will it generate? Does it offer cost saving opportunities? Are there intangible benefits that will be accrued? Ultimately is it a viable proposition that is worth pursuing, or will the cost to develop and run outweigh the value it will add? Building out a financial model can take time, in the first instance this should be a napkin analysis, a wake-up call to make sure there is value in the proposition before too much time is invested in it.
Every day someone is working on the proposition it is costing you money. The quicker you can get something to market the faster you will start seeing a return on your investment, similarly the sooner you can “get something out there”, “test and learn” the sooner you can kill a proposition that does not fulfill its promise.
- How quickly can you get a beta to market?
- How many people, how many days?
- What will the cost be to develop the infrastructure?
- Do you have the skills in house or will you need to go external?
Benefit / Revenue
At its most crude, how will the proposition make money, but there may be more to what we wish to achieve. Is the proposition actually going to cut costs, a result of regulatory pressures or a CSR initiative?
What are the benefits that will be accrued – both tangible (e.g. financial) and intangible (e.g. social, environmental etc)
- If you are selling units are you going for high volume low margin or low volume high margin?
- If it an on-line proposition “advertising” is often seen as the source of revenue.
There are two additional components to the model…
Having a compelling proposition is one thing, it is another to successfully communicate it and roll it out to target customers.
- In a crowded market place, how will the proposition stand out?
- What are the brand values it will communicate?
- What is the story that customers will hear and how will they hear that story?
- How will customers interact with the proposition, what channels will you use to take it to market?
- What is the roll out strategy?
Retain and grow
Winning customers is only the first step. A successful proposition will maintain a long-term relationship with its profitable customers, maintaining the warmth they have to the original proposition and cross-selling and up-selling new ones.
- How will you retain them and turn them into repeat customers and passionate advocates of the proposition?
- How will the proposition grow lifetime customer value?
- What can be cross-sold or up-sold?
- What can you bundle?
- How will the proposition deal with churn?
OK, so it’s not a perfect model and by no means complete. There’s some duplication in the thinking and many questions missing, but as any model it can be used to guide and prompt thinking and ensure there are no elephants left in the room when the first line of code gets cut. I’d welcome any comments on its usefulness, utility and direction.